While I think this is worth exploring, at a certain point you end up doing so much that you could just write raw HTML, and then you'd have the advantage of being able to display it directly in the browser and using Javascript's powerful querying features.
To meet modern requirements and make documents dynamic, we need a flexible API and integration with contemporary frameworks. Simple HTML just isn't up to the task. Although this was the approach during the early implementation (https://github.com/zag/js-pod6), it turned out to be a dead end.
I had all kinds of plans for my knowledge management for over a decade. Then I started using org-roam and now the activation energy to consider anything else is so high that I'm stuck in a local minimum.
I had the idea that handwriting, an infinite canvas and cross linking between ideas were going to be a big part of my external knowledge base. So I learnt a lot of technical skills that would allow me to put something like that together. Then right around the time I got an eink tablet and thought I'd start making something, I started using org-roam and it seems more than enough to contain all the information I tend to want to record. If I really want to handwrite or sketch something, I'll just do it on paper and snap a picture, crop it and paste it in Emacs (I have a script that copies it into a subdirectory) and the whole thing lives in a git repo.
To quickly locate, via artist-mode the spot to be filled in a pdf, view via pdf-tools https://github.com/Nidish96/cart.el as dummy handwritten fonts I like:
\usepackage{pbsi} % for most text except all-caps
\usepackage{fontspec} % for all-caps, require XeLaTeX o LuaLaTeX
\usepackage{pifont} % for check marks
\usepackage{xcolor} % for a dummy ink color
\newcommand{\blue}[1]{\textcolor{blue}{#1}} % as a handy wrapper
usable like, for as much pages as you need (a \clearpage between them)
% block for page 1, repeat the block for 2, ...
\begin{tikzpicture}[remember picture,overlay]
\node at (current page.center) {\includegraphics[page=1]{ToBeFilledPDF}};
\begin{scope}[shift={(current page.south west)},every node/.style={anchor=base west}]
\node at (50mm,237mm) {{\blue{\bsifamily normal text}}};
\node at (29mm,170mm) {{\blue{\fontsize{12}{13}\selectfont\bsifamily scale text size as needed}}};
\node at (62mm,199.7mm) {{\blue{\ding{51}}}}; % a checkmark
\node at (135mm,24mm) {\includegraphics[scale=1]{signature.png}};
\node at (1mm,2mm) {{\blue{\fontspec{QTChanceryType}\bfseries ALL CAPS}}};
\end{scope}
\end{tikzpicture}
where coordinates came out from cart.el wizard-clicks, then eventual small change by hand to perfectly align. It's not super quick, Xournalpp is quicker, but via LaTeX you can input anything, with very nice dummy handwritten fonts, you can add images if needed (for instance insurances form at least in Italy/France) etc. Next step is eventually make them (a bit long) a PDF/A, adding an eventual vector version of the signature, adding an eventual PADES signature or even embedding the LaTeX source into the pdf, just to teach a lesson to those who in the 2024 still send non-fillable pdf forms meant to be printed, filled by hand, scanned back...
That playground is cool. I wonder if there are any 2-way playgrounds where the right side is also editable using a Word / Google Docs style interface (and the changes are reflected in the code-style interface on the left). I've always wanted something like that for teaching non-technical people the basics of Markdown. Bonus points if it's collaborative.
This is a wonderful and highly sought-after idea. However, it requires significant resources, so we will definitely come back to it and implement it. Thank you
Although it's already on your roadmap, but it definitely needs more complex examples. Fiddled around a bit with links to same-doc references. Got it to work, but took a while.
AsciiDoc is much nicer, but has the unfortunate flaw of having basically one implementation and it's in Ruby (the JS one is just transpiled, the Java one runs on JRuby, not sure about Go and Haskell).
They don't even have a Python library, which basically guarantees that AsciiDoc won't be taught in colleges.
I like AsciiDoc, but not nearly enough to mess around with installing Ruby and Gems and then having to do the same for anyone else at work that needs to build the docs for whatever reason.
Ruby is basically a non-starter for me in general. Dependency management and interpreter versioning is a pain in the ass for interpreted languages, so I'd rather have as few as possible on my system. I've already got Perl and Python installed by default, I'd rather not add a third.
I'm still upset that Markdown ended up getting all the mindshare and doesn’t evolve. All the fragmentation through different markdown flavors doesn’t help.
Perl's POD, yes. But you're right! The spec authors are Perl folx, and this is clearly derivative. What's kind of interesting is that POD stands for "Plain Old Documentation" and then there's a "lite" version of it... so "lite-r Plain Old Documentation" --- I don't see a clear summary of the differences, though.
Reading through the source for the specifications was interesitng.
There is a lot of good stuff here, but there is so much to learn
but I dont see enough benefits to push me to learn it when I
already have Latex,Markdown and straight HTML in my toolbox.
Podlite indeed looks promising, especially with its extensibility and support for Markdown. I agree that if a markup language gets too complex, using raw HTML might be more advantageous. However, I think the strength of Podlite lies in its universality and flexibility, allowing it to adapt to various project requirements.
I'm particularly interested in the extensibility of Podlite. This feature allows the language's functionality to be expanded according to the specific needs of a project, which could be a huge plus in many cases. I look forward to seeing how Podlite evolves.
As for using raw HTML and JavaScript, while they indeed provide powerful querying features, Podlite might be simpler and more intuitive for those who are not familiar with these technologies. I think that's another strength of Podlite.
All in all, I think Podlite is a project worth watching. I'll keep an eye on its progress and look forward to seeing what changes it can bring in the future. Thanks for sharing this project!
I would love to have a notation to get a various ways of representing of intellectual tasks into a single document. A real killer feature in my eyes would be if a kind of umbrella markup language would support a convenient two-way binding for creating and manipulating notations, so for example that diagrams could not only be rendered in a desktop app, but also be manipulated with the markup being automatically being updated. I guess the problem is that light-weight implies too little structure to make such a thing easy to implement...
I think you've lost the point of Markdown: it's readable as raw text.
I was excited that this was an extension of markdown but now I that see it I react with horror: markdown is not a programming language. This looks rather like a programming language.
Wow. This is so good. For reference:
It is 4 times smaller than HTML.
It is 29.5 times smaller than PDF.
It has a really good structure and is more readable than Markdown (sometimes).
The existing typescript implemetation builds a complete AST (Abstract Syntax Tree), over which middlewares are run in several passes. Yes, there are multiple passes over the tree. This is necessary, among other things, to build a table of contents (TOC).
thank you
Might not work for my use case then. djot is single-pass so dovetails better with forth-style languages.
I do like the blocks and mistake marking though :)
Interesting. Have you been using djot for anything substantial, like technical/academic publishing, large projects like entire books, or similar? How does it fare and what is your toolchain? Thanks in advance!
I'm trying to use it as part of a new forth-style language, hence the need for single-pass.
I've found it as easy to use as markdown, but more regular ie. Well defined, which suits a language spec.
The key parts for me are reference links for execution-thread documentation and ``` blocks to program literally, (and separate/scope comments // from documentation """)
The toolchain as such is just part of the language- the compiler needs to parse djot. I'm not fully there though.
Ouch. IMHO the reason markdown became so popular is because how simple it is, how well the syntax generally stays out of the way of the content, and its almost entire lack of mixing formatting with document structure.
This is VERY heavy, and VERY invasive. The entire lack of opinion in "use whatever markup you like as long as its wrapped in our markup" seems like an extra awful complication. I'd be curious to hear about what concrete problems the authors of this spec were trying to solve and why they went so far.
What I find most interesting is that there’s no need to choose between Podlite and Markdown; you can use both and switch between them as needed.
I think Podlite could be really useful in document management systems and electronic publishing. But... let's see what practical uses Podlite will find.
This introductory blog post from February is useful too: https://podlite.org/2024/2/21/1/introducing-podlite-a-lightw...
To meet modern requirements and make documents dynamic, we need a flexible API and integration with contemporary frameworks. Simple HTML just isn't up to the task. Although this was the approach during the early implementation (https://github.com/zag/js-pod6), it turned out to be a dead end.
thank you
https://github.com/podlite/podlite-specs/blob/main/Specifica...
Also online playground is available here: https://pod6.in/
Thanks for your interest in Podlite! with best, Alex
Although it's already on your roadmap, but it definitely needs more complex examples. Fiddled around a bit with links to same-doc references. Got it to work, but took a while.
Markdown is perfectly usable.
They don't even have a Python library, which basically guarantees that AsciiDoc won't be taught in colleges.
I like AsciiDoc, but not nearly enough to mess around with installing Ruby and Gems and then having to do the same for anyone else at work that needs to build the docs for whatever reason.
Ruby is basically a non-starter for me in general. Dependency management and interpreter versioning is a pain in the ass for interpreted languages, so I'd rather have as few as possible on my system. I've already got Perl and Python installed by default, I'd rather not add a third.
https://gitlab.eclipse.org/eclipse-wg/asciidoc-wg/asciidoc.o...
It’s a long shot, but if GitHub/GitLab added render support for AsciiDoc my life would be complete.
Regardless, it’s impressive and awesome progress.
I believe that natural evolution makes it easier to let the bad branches die out.
I would like to be proven wrong though.
I'm particularly interested in the extensibility of Podlite. This feature allows the language's functionality to be expanded according to the specific needs of a project, which could be a huge plus in many cases. I look forward to seeing how Podlite evolves.
As for using raw HTML and JavaScript, while they indeed provide powerful querying features, Podlite might be simpler and more intuitive for those who are not familiar with these technologies. I think that's another strength of Podlite.
All in all, I think Podlite is a project worth watching. I'll keep an eye on its progress and look forward to seeing what changes it can bring in the future. Thanks for sharing this project!
I would love to have a notation to get a various ways of representing of intellectual tasks into a single document. A real killer feature in my eyes would be if a kind of umbrella markup language would support a convenient two-way binding for creating and manipulating notations, so for example that diagrams could not only be rendered in a desktop app, but also be manipulated with the markup being automatically being updated. I guess the problem is that light-weight implies too little structure to make such a thing easy to implement...
I was excited that this was an extension of markdown but now I that see it I react with horror: markdown is not a programming language. This looks rather like a programming language.
Does this use a single pass for the parser? Is there an EBNF spec? What sort of diagrams does it support?
Thanks
I've found it as easy to use as markdown, but more regular ie. Well defined, which suits a language spec.
The key parts for me are reference links for execution-thread documentation and ``` blocks to program literally, (and separate/scope comments // from documentation """)
The toolchain as such is just part of the language- the compiler needs to parse djot. I'm not fully there though.
At the moment only typescript implementation exists and here is PEG grammars from it: https://github.com/podlite/podlite/blob/main/packages/podlit...
At the moment it supports Mermaid diagrams:
https://pod6.in/#p=%3Dbegin+Mermaid++%3Acaption%28%27Caption...
This is VERY heavy, and VERY invasive. The entire lack of opinion in "use whatever markup you like as long as its wrapped in our markup" seems like an extra awful complication. I'd be curious to hear about what concrete problems the authors of this spec were trying to solve and why they went so far.
What are the advantages of the Podlite design?
---
=toc head1, head2, head3
=begin markdown
---https://pod6.in/#p=%3Dtoc+head1%2C+head2%2C+head3%0A%0A%3Dbe...
What I find most interesting is that there’s no need to choose between Podlite and Markdown; you can use both and switch between them as needed.
I think Podlite could be really useful in document management systems and electronic publishing. But... let's see what practical uses Podlite will find.
thank you