My FOSS text editor, KeenWrite[1], takes a similar approach: Markdown -> XHTML -> TeX -> PDF. The software architecture shows how you can have processor chains:
I developed KeenWrite to help write a sci-fi novel where I can use variables for character names, places, etc. See the tutorials[2] for details.
For anyone still using pandoc and shell scripts, my Typesetting Markdown[3] series describes building a script-based infrastructure for converting Markdown into PDF.
I was really excited when I read your post. I've long looked for a good MarkDown -> PDF or RTF workflow, so I gave KeenWrite a quick try. At first glance I really thought I'd be exactly the user for this tool, but quickly realized that the discoverability of KeenWrite isn't nearly good enough.
Upon launch, I'm presented with three panes. I've got a MarkDown authoring interface and an output preview. Great. I drop in some markdown and it renders.
Then I have a "variables.yaml" pane open with three little controls, "Create", "Rename", and "Delete". Ok... I'm editing a YAML file. But it's a clunky nested node editor. People can edit a MarkDown file but you don't think it's faster to simply let people edit YAML in text?
So, I get it, I'm editing a YAML file that stores metadata about... SOMETHING about my document output. Except I don't have a single example of a variable. Not a single one. I have no idea what variables are available and exploring every single menu option tells me nothing. Help only provides a small about page with no link to the documentation.
So, I go to keenwrite.com and click documentation. It takes me to a single GitLab readme that talks about different command line launch options, and then finally how to begin to use metadata, but the options all revolve around creating an .Rmd file and using R or creating a "definitions.yaml" instead of a "variables.yaml" in a seperate editor.
This is the moment I realize there's no chance this tool is going to be useful for me.
Were the video tutorials[0], in particular the variables tutorial[1] not helpful?
> Except I don't have a single example of a variable.
Did you watch the metadata tutorial[2]?
> People can edit a MarkDown file but you don't think it's faster to simply let people edit YAML in text?
Close the variable editor panel if you like and edit the variables in a different text editor. (Or create a symbolic link between the .yaml and .yaml.txt file and edit the .yaml.txt file in a KeenWrite tab.) The downside is that KeenWrite won't know how to inject variables into the document when pressing the Control-Space hotkey.
The variables, architecturally speaking, need not be written in YAML. They could be TOML, XML, JSON, etc. The software reads a nested hierarchy of variables and values into a tree data structure, which abstracts away the data's file format. Presently only YAML format is integrated. The hierarchy is then presented through a clunky JavaFX Tree UI element.
> discoverability of KeenWrite isn't nearly good enough
I received that same feedback years ago and made video tutorials, which are linked to at the bottom of the home page[3]. Do they need to be more prominent?
The home page also links to a documentation page[4] that describes variables, metadata, R integration, and more.
For me, the issue is not document conversion and is content de-duplication. Product A and Product B manual will share number of sections. Any spelling or grammar error must be updated in Product A and B manuals. They man share the same additions.
So far LaTex has been the only solution to allow binding shared sections into multiple document builds. These are for internal and customer facing information. Only binding duplication is in the revision overview sections pertaining to each document build.
> So far LaTex has been the only solution to allow binding shared sections
R, being a Turing-complete language, can do this. If R Markdown can do it then KeenWrite and pandoc+knitr support it. R can also do conditional includes. For Product A and B to share authentication steps, this could look like:
`r#inc( '../common/authentication.Rmd' );`
Where TeX may resemble:
\input ../common/authentication.tex
SGML, DocBook, AsciiDoc, RST, and other text formats have similar abilities.
Looking at the "mock" document (https://github.com/iamgio/quarkdown/tree/main/mock) which is supposed to be a comprehensive and detailed guide for all visual elements, I don't see ways of getting anything other than basic markdown tables. How do you get merged cells? Cell formatting? Typst has some nice ways of implementing sophisticated grids and tables.
Also how do you implement things like different page numbering for front matter content and the main content? In general, the "simplicity" of markdown seems to be taking away a lot of granular control that people use LaTeX and Typst for.
Thanks! The main thing that I had difficulty with, which you can see from the typst source, is the rendering and spacing around inline math symbols. They are rendered as SVGs, which is fine but then copying them doesn't work. Their spacing is sometimes unpredictable so I'll add something like $thick x + y$ to pad on the left hand side. I'm not sure what parts of the math symbol contribute to the dimensions of the SVG and I'm sure it's rather complex, but other than that the experience has been solid.
It's very much worth it, but absolutely not necessary. You can always generate images/figures beforehand and include them in Typst. There are also packages for various styles of diagrams, e.g. diagraph ships with a Graphviz renderer.
There is also CeTZ, which this article uses. It is highly inspired by TikZ and is just as powerful.
>And surely the learning curve is not easier than Typst?
To be fair, (most) markdown is valid Quarkdown. Barrier to entry really doesnt get any lower than that. Of course the learning curve is not fully synonymous with the barrier to entry, but it's a significant part.
And "learning curve" is really such a subjective quality. Kinda fucked from the start once you put it in a comparison table. Explicit features are more objective but even then sometimes products dont NEED certain features because of their design.
Not sure I understand. I never said anything about my use cases. I was checking the accuracy of the comparison table. Did you mean to post that comment here or were you replying to another comment?
I guess that the similarity of the names come from different places, and in this case might be a remembrance of QuarkXPress. It's convergent evolution! :D
I guessed the name derived as follows: Quarks as the smallest particles, a view in most detail, the building blocks of things. Typesetting as the lowest level of abstraction for creating a document, "down" from Markdown.
People may not know it but at some point in the nineties you'd enter a bookstore and 95%+ of all the books and magazines were typeset using QuarkXPress.
Then Adobe's InDesign showed up in 1999 and things began to change.
FWIW I both wrote and typeset books myself (for a traditional publisher): I did most of them using QuarkXPress but I managed to sneak one I made with LaTeX (it was a hard sell to the publisher / printing press guys who were only ever using QuarkXPress). Also I was forced to heavily modify LaTeX templates to match exactly the one the publisher was using with QuarkXPress.
So yup when I read "Quarkdown is a modern Markdown-based typetting system" the first thing I think about is QuarkXPress: great memories of MacOS (8? then 9?, pre OS X for sure) and my Sony Trinitron monitor.
Was going to ask the same question. Was talking to a friend just 2 days ago who redid all his lecture scripts with quarto and embedded the lecture presentations. Looked neat. Also that quarto interacts well with R studio and jupyter notebooks comes as a big plus.
But I always hate it when a templating language grows function calls and all of that. Maybe it makes sense in this context, I'm not sure.
But if you end up using it together with another language, maybe for server side rendering or some kind of document from data generation, you quickly realize that switching between the two languages wastes a lot of time, and the templating language is never as powerful as the "real" language. So I prefer JSX, or something like Javascript's tagged template literals. Something where you use a real programming language, but where the context of the document is understood, so you don't have to worry about escaping or XSS.
This, Typst, etc etc are primarily typesetting systems for papers.
I would love alternatives to HTML or whatever, but I tried Typst too and it's very clear that the authors only really care about typesetting for papers and other long form prose. Stuff like forms, invoices, flyers, handouts, leaflets, business cards -- an afterthought, at best.
Edit: Actually I was thinking of Sile not Typst, but I think the same applies to Typst too. I didn't dig into Typst too much because it was commercial though.
> Stuff like forms, invoices, flyers, handouts, leaflets, business cards -- an afterthought, at best.
It is because you can typeset beautiful long text algorithmically and all these small forms like invoices and flyers are more graphical design than typesetting: you need to place many small elements precisely, not relative to each other but to the edges of the page / optical centers / etc. It is not very convenient without WYSIWYG. Possible, yes, but will require many trial-and-error when in WYSIWYG layout program can be done from first try.
Think about tabloids too: text, which wraps around non-rectangualr images, cut-outs, etc. Hard to do without seeing what you do, only with text and coordinates.
I don't agree. Plenty of people write HTML by hand, no WYSIWYG, often with no more than a live preview pane like Typst's.
Why isn't it easy to place something relative to the edges of a page via text? In HTML I do `padding: 2cm` and I'm done. I'd say most of design involves placing elements relative to eachother; half the constraints in GUI design tools are matching spacing or aligning to nearby elements.
I'm not saying you can do the whole thing blind, but for the odd thing that does need visual feedback, not having a convenient UI isn't a critical failure. Some of those things are hard to do in a GUI too, and having a good text based layout tool could be easier.
On the other hand, all "official-looking" documents like invoices (with complex headers and footers) I seen in HTML was ungodly mess of nested tables, not something clean and structured.
I don't say it is impossible. But looks like it is hard.
Is there any reason why you can't use Typst for any of the stuff you mentioned? I can't see why you couldn't (except for interactive forms, which is already being worked on [1]. The pdf-writer low-level backend seems to have already implemented support for form fields, so it seems like a matter of time until it is implemented in Typst).
I believe you can do those sorts of layouts in Typst (and Latex, and Sile!), but it's about how far out of the way you have to go and how much you fight the system in the process. I don't see any examples of Typst doing anything other than papers, I believe for good reason.
To be clear, I mean from a design perspective. Like take a print copy of Wired... how hard would it be to replicate any of those pages? Without using other software (aside from maybe cutting up stock photos). I can format scientific papers in HTML and it's not too hard, I can also format a cookbook, and it's not that hard. It's not great either!
I found it much easier to use Typst to create any of these documents than any other software I used before. Just loading data from a JSON and incrementally regenerating the document on each change is game-changing for me.
Honestly, I don't think that it would be too hard. With the grid function you can do a lot of things, specially because you can use grid.cell(rowspan:3, colswap:4) to make cells that span multiple rows or columns, use fractional sizes for the columns (1fr, 2fr, etc), and add independent insets and strokes for each cell, so you can already do a lot of the things you can achieve with css flexbox.
Though I suppose the docs could include tutorials for how to use them to make a more diverse kind of documents, and adding another layout function that behaves more like flexbox would be nice (though it wouldn't be too hard to create a function that re-creates the behaviour of flexbox based on the grid function).
The online editor is commercial. They have a github repository releasing Typst under an Apache 2.0 license for free. I installed it using cargo (Rust), and don't use the online editor.
Oh, I didn't realize that! I can't shake the feeling that the open source community engagement might cater to paying customers, but I'll need to take a closer look!
You can use typst locally and bypass the commercial bits. It is really easy to create different kinds of documents with it. I have been using it to create slides and handouts, and for that I already find it much easier to use than the alternatives.
Look at Quarto. Markdown input, basically any output you want, including HTML, PDF, DOCX, PPTX, etc... All from the same input. Reuse text chunks, use variables, templates, and more. Then just run 'quarto render'.
My first "real" usecase for Typst was a poster [0], since it was much easier than doing it in LaTeX. It's missing some features, like wrapping around figures and flowing text between boxes, but TeX doesn't have the second either and both are planned in Typst.
That looks interesting, and to be fair right now I'm doing something similar... but doing headless rendering with that sort of stuff is very hard, AFAIK the standard tool for that has been abandoned now for a couple years. Also there are other issues with browsers, like creating CMYK PDFs.
Since 70% of comments under each of these posts are always "why not LaTeX?!", I want to start by reaffirming: yes, I do want a modern Markdown-based typesetting system. There even is a place of several of them. It would be absolutely nice to replace LaTeX, simply because it's old trash with remarkably inconvenient syntax, so, yes, a system with full control over markup is desirable. And if it necessarily increases verbosity, then there absolutely is a place for something "just a touch more powerful than markdown".
However, at a glance it doesn't strike me as what I was looking for. There aren't too many examples, but it seems like it leans heavier towards "just a touch more powerful than markdown" rather than to "replace LaTeX" (or Typst, for that matter). And for the first scenario to play out, it must be really seamless to use. This one doesn't seem to be.
1. Just to take care of the elephant in the room: JVM. Same as many others, I won't even bother installing it to try it out, so it doesn't help virality much.
2. I don't like the syntax. It needs to be as compatible with plain markdown as possible, and this one isn't quite. My main issue is with argument to a function being tabulated. It seems like it will lead to the whole document being tabulated. It is a natural for markdown-compatible add-ons to employ a code/monospace blocks, but ```plugin-name is a better way to do it, because it doesn't mean you have to reformat your whole document when you decide to step off from plain markdown.
3. Since a "better markdown" is something more suitable for something that starts as your personal notes (if you are specifically working on preparing a document for publishing, indeed you can just do it in LaTeX as well), I suppose it's only useful to an extent it is integrated into your notetaking app. Surely, there are still some people who do it in Emacs or Vim, but even such a retrograde as myself eventually moved on to Obsidian. I want ways to control my document structure better inside my notetaking app with a potential ability to publish. But as a standalone thing, I'm not sure why would I use it. At least Typst has a proprietary online editor. I suppose, that's also how nearly everyone uses it.
I’d argue that Typst probably beats it on all levels. Have you ever seen a LaTeX document? (The question is rhetorical, of course you have) Just because it was the best thing before doesn’t mean it still is now. I’d say the only thing it still has going for it is momentum.
I looked at the Typst documentation and from what I could tell, it has 3 hard-coded "Modes" for 3 hard-coded kinds of syntax (normal, math, code). I couldn't find any way to add any custom syntax - is there a way to do this?
Tex/LaTeX are completely syntactically extensible. For example, a logician might want to use the software with any number of their notations, or a physicist drawing Feynmann diagrams, etc. I think at one point Lillypad used it for typesetting sheet music.
I hated most Latex syntactic extensions that I ever has to deal with. They basically force you to learn completly different languages, each with their own quirks. I found simple function-looking macros to most often be more intuitive and reliable.
You know what, while you're at it, I might as well bring it up. How about XML?
I haven't really tried writing large pieces of text in it but I am already seriously considering. All other alternatives are too complicated and have a learning curve that gets in the way of writing itself. With XML, I'd be able to define my own tags and run them by a parser later on to auto-generate indexable footnotes, and create my own ways of structuring text besides the usual ones (chapters, sections, etcetera). Has anyone tried this approach?
Professional tech writer here: We use GitHub and a tool called OxygenXML to write docs-as-code in an XML DTD called "DITA". It's a hefty IBM invention from the early aughts, but it covers every use case I've thrown at it, from small documentation sets to multi-thousand-page monsters. Supports PDF, HTML, Word, and many other output types.
DITA's so great at everything _except contributions from non-tech writers_ that half of my career has involved migrating tech writing stacks that use it to Markdown/SSGs in git repos.
DITA's benefits require a certain scale that most tech companies never achieve. And the Open Toolkit is a nightmare piece of software.
Agreed, and we use Markdown where we can. But inevitably some product manager comes along and demands tables inside tables or embedded reuse of content... and it's back to DITA.
OxygenXML makes the OT much more manageable. I haven't had to touch an OT XSL transform in a few years now. Worth every penny.
Yeah last time I touched it was during an internship 15 years ago, the few memories I recall were not enjoyment at all (however I was using LaTeX everywhere at the time).
Writing documentation as XML is powerful but not enjoyable at all I guess
I have been thinking about this seriously myself. Not with a specific existing schema like DocBook, but with a custom schema (defined by me) that I then compile to standard schemas, like DocBook or HTML.
This seems extensible to the degree that I want (i.e. semantically rich enough that you can conceivably hang any application from it). But I just can't bring myself to write in XML syntax, especially for maths.
Well basic markdown is super useful to do stuff quickly.
Problem is when people started to build systems upon systems upon something that should not be used for more complicated cases.
Maybe not a problem because I don't care but I just see how loads of things that someone created to be "just that" someone takes without understanding and builds on top instead of understanding limitations and scope of the initial idea or system.
It is "oh it is missing a feature" - where it is "no it wasn't built to do that".
I have seen notepad in windows shipping some formatting features, I don't see that as an improvement. Notepad was notepad for purpose.
I think a good balance for a markdown syntax is something you can write nearly naturally on the fly (very low syntax needed for basic use) but can continue to mark up in more detail when you want to turn something into a complex use case (very high syntax ceiling for the complex cases). HTML+CSS almost gets there except the tags are a bit awkward for simple things like just <strong>bolding</strong> a word.
Regarding Notepad, keep in mind they dumped an entire separate app (WordPad) by merging the ability to format into Notepad. This kind of mirrors what I was talking about above: one app with a very low floor but a flexibly high ceiling when you want to go there with it rather than two separate apps you need to pick from up front.
Does org-mode have a spec? From what I've seen, org-mode is defined as whatever Emacs does. Without a spec I can't see how it's a viable format for widespread usage.
1. Spec, written after the fact, not by a core dev.
2. Live help in 'org-info'.
3. Elisp string extraction via 'M-x describe-function' and the like.
Difficulties arise from subtle inconsistencies between the three, and inability of any one to comprehend the kitchen-tool-bin jumble of low- and high-level functionality that has been added over the years.
OTOH, content display is economical of eye and finger effort, and some of the Emacs interaction features startingly powerful.
I wrote my own, use-case specific converter to expand org-format to HTML. Runs on the CL, written in Go.
Personally, I don’t see the point. Searching for markdown libraries is not hard, a good library (the same that will show up first) will show you usage instructions at the top. You can copy-paste those and be done.
Also modern JavaScript uses import, require() is very 2015. If the AI is recommending you use require() I would suggest a better one.
If 2005 text editors autocomplete made it easy to balance and indent html/xml tags and syntax highlighting like today, would JSON, Yaml, Markdown have taken off? In The Art of Unix Programming from 2003, the author states editing xml by hand is torture, hence we must invent unique text formats and parsers for the same.
I have not been able to configure an editor that makes it less painful. I think it's not just the verbosity (although that is painful) - the prefix notation makes some things inherently hard to read. MathML is almost impossible.
Ah yes, writing my notes down in css and html. My favorite!
Seriously though, every time some new hotness comes along, you don’t really have to use it or even waste your time looking at it. Markdown will likely be here after all of its derivatives are long gone.
For me the only addition to markdown I usually enjoy is mathematical typesetting like on GitHub using the inline $$ syntax or the code blocks with the language set to `math`
> What could be mistaken for a planet is actually a quark or, more specifically, a down quark, an elementary particle that is a major constituent of matter: they give life to every complex structure we know of, while also being one of the lightest objects in existence.
Cool project, but seems dangerous to use the word “Quark” in a publishing context RE: QuarkXPress:
I strongly suggest that the greet call uses a slightly different syntax (e.g. two dots) as the system otherwise can't introduce new keywords without risking conflict with function names in existing documents.
Does it need more keywords? This syntax reminds me of Smalltalk syntax a little and Smalltalk famously got away with merely 6 keywords. I didn't check the syntax in detail for quarkdown, and I don't expect it to be as well thought out as Smalltalk, but it is quite possible to get away with only few keywords. Question is then how complete their concept is right now. Also there could be a versioning mechanism, that labels a document as for a specific version of Quarkdown.
if you have a UDF called .until and then this becomes a keyword, does the new 3rd party library you start using that uses the keyword .until still work, and what does the LLM vibe-coded start doing in the future when it makes use of the .until keyword?
I like it for what it is, a layer on top of markdown. That said, the main usage of markdown for me is that it's just the content and it doesn't have any opinions on the layout let alone logic.
I can add those with the use of css/js for web and interpreters and themes for print/non web.
Interested in this! Recently wrote a thesis. Wanted to use markdown, but that had too many limitations.
After learning and using LaTeX for a bit I got used to it, but the overall experience of setting it up and its usability leaves a lot of room for improvements. But on the other hand it's established in academic writing.
Do hope to see something based on markdown be able to replace LaTeX in the future.
With Emacs and AUCTeX and a few macros for tab completion I could generally transcribe a math lecture in real time. If you're using completion then the verbosity isn't a downside and in fact helps add structure for automation.
The main drawback for writing something like a thesis is that LaTeX not great to outline in. I think for my thesis I ended up doing initial drafts in org-mode and exporting into LaTeX to view it.
Then once the overall structure took shape I edited the LaTeX directly. Otherwise you end up having to embed LaTeX markup in your markdown doc because markdown is underspecified compared to TeX.
Quarto is probably what you're looking for. It's what we've been using for scientific publications in gov science research labs the past couple of years. Can output to LaTeX and incorporate templates and such.
Very intriguing. I write my resume in a blend of LaTeX and Markdown, use Pandoc to convert the file to LaTeX, which then gets turned into a PDF. This might be a tidier solution on the front end, though I like my current flow because the maturity of all the tools means I can come back to my resume after several years and it'll still compile.
The comparison to LaTeX is a bit unfair... the latex code is much larger than it needs to, and does things that the quarkdown doesn't (like floating the figure in the page).
Once you remove that, both versions look essentially equivalent and just as readable.
The words "begin" and "end" are very readable, actually. "includegraphics" as well. Remains the aversion against backslashes. What exactly do you find less readable about them than other symbols like for example the colons or braces in Quarkdown? Or is it about the number of backslashes?
Actually, no, if markup takes more space than content, it hurts readability of the content. Especially for such common stuff like images.
But if you don't see this obvious barrier, I will unlikely be able to explain the issue with backslashes: it's partially about the number, but also visibility - .period syntax is a smart choice as it's unobtrusive and not part of the regular syntax, and it's more ergonomic to type, so a universal win.
I get that people don't like the braces in TeX but ... :-)
I'm only half sarcastic here, I don't like them either. I have recently been using pandoc[1] to do the things they are talking about, I had added some stuff in perl using the Template Toolkit[2] to make HTML pages. My issue is that I have very different fugue states for writing vs. coding. Switching states breaks my flow so I've been trying to make the two modes as orthogonal as possible.
I'm curious if anyone has used something like this to go straight to PNG. My use case is that I have a surplus epaper display that can display pngs it fetches from the network and I've been forwarding it my todo list. Have been doing this with a LuaTeX flow but would like something a bit more seamless.
Because muscle-memory is a powerful force, and it's a convenient universal input language.
It's why after years of powershell I still reflexively reach for "ls" not "Get-ChildItem"
( "ls" is aliased by default to Get-ChildItem thankfully! )
Markdown is familiar, easy to use, and very human readable and editable without fear of breaking a compilation step.
Typesetting languages however, TeX, LaTex, postscript or the nightmare of the PDF spec, are not.
If I send someone who doesn't know anything about a document markdown, then there's a good chance they'll be able to make simple edits in their favourite text editor and not screw things up.
If I send someone HTML, they'll likely be able to do simple edits but there's greater risk of breaking elements or styling. Not as bad as with stricter languages, but still significantly more chance than with markdown annotations.
If I send someone some TeX, they'll probably not know what to even do with it, they'll likely get confused and ask for a file format they can use.
Reducing how many different languages we have to master is important, so I think it's great if there's a way to write everything in flavours of markdown.
Write markdown everywhere, and let the backends compile to relevant outputs.
In this instance, it's left perhaps a bit function-heavy so there's still larger "risk", but that's likely something that can be solved through templating.
We have flavours of MD, for github issues, for typesetting, for stackoverflow questions. Slack and Discord have (limited) MD support. We can write blogs in MD through jekyll.
MD is everywhere, it's a convenient universal input language.
InDesign is awesome. Anyone designing a general purpose document language should spend a lot of time in InDesign first. LaTeX should not be your mental model.
I would like to have a compiled demo PDF available for download, along with a direct comparison of the same paper created in LaTeX. I would like to see the differences both on screen and in print.
Is this standalone, as in: an actual file format people can use? From their website it looks like it won't work without using their service or hosting something yourself?
I was a bit surprised to see Kotlin as the main language (I quite like it, but had to move away from JRE-based anything) I hope it can be built as a native binary...
There is kotlin native these days; so not impossible.
Kotlin is kind of nice for this stuff; which is probably why they picked it. IMHO Kotlin is undervalued as a python replacement; it's pretty convenient for a lot of data processing stuff. And being able to use whatever Java libraries are around is also not a bad thing.
Anyway since it is kotlin, you could use kts (the scripting support). You'd still need a jre and kotlin installed but it would make it easy to invoke from the command line and it would be able to pull in jar file dependencies straight from maven central. There might also be a possible path to build this thing via Graal and package it up as native. Another option is to package everything with docker and call it with a simple shell script. And finally, Kotlin has a native compiler as well but I assume there are too many jvm dependencies to be able to use that.
So, there are a few options here to make using this more convenient.
Which is where MyST [0] gets its structural cues. That's another alternative missing from the comparison table of this project, and an interesting one for how much it seems to be going for the science community that loves Jupyter notebooks.
Had a chance to read the wiki/docs deeper. Quarkdown seems to use puppeteer and chrome-print-to-pdf to generate PDF from HTML [1].
So, aside from the more minimal format or Markdown compared to HTML, I don't see much appeal in quarkdown compared to feeding HTML to a headless chrome instance.
But it is a cool project if one wants to turn a bunch of markdown files to say a book or an article.
> From a technical point of view, WeasyPrint is a visual rendering engine for HTML and CSS that can export to PDF. It aims to support web standards for printing. WeasyPrint is free software made available under a BSD license.
> It is based on various libraries but not on a full rendering engine like WebKit or Gecko. The CSS layout engine is written in Python, designed for pagination, and meant to be easy to hack on.
Cool, not who you replied to but this is a cool idea, another way to archive pages. Gotta compare it to singlefile and headless chrome - I've been looking for a faster way to get a snapshot of a webpage via a chatbot (like in discord or matrix). Used to use Firefox headless, but large pages/slower sites would time out the api.
The syntax feels complicated. Maybe I just don't have enough patience for learning a typesetting syntax (I never worked with Latex before).
On top of that, there is no easy way to create a template. For example, I want an invoice template which I can reuse with different data. Theoretically, I can create a typ file for the template, and define the invoice as a function which I then call from a string with, say, json data. It seems great as web service, but not as a library I can use from, say, Rust.
And the type system is a bit confusing. I can define basic types like numbers or string, but when it comes to structs, they don't seem to have support for that.
I find it easier to create a handlebars template, and feed the HTML to headless chrome printing service, which will output a PDF for me. It's not scalable for high volume, but good enough for my needs (takes about 2-3 seconds to generate PDF).
> On top of that, there is no easy way to create a template
Templates are just functions [0].
I think much of the frustration comes from typesetting being a harder problem than it seems at first. In general a typesetting system tries to abstract away how layout is recomputed depending on content.
Supporting contextual content -- cases where the content depend on other content, e.g. numbered lists, numbered figures, references, etc -- involves iterative rendering. This is evidentidly a complexity sinkhole and having a turing complete script language will bite you back when dealing with it. I recommend reding their documentation about it [1] where they explain how they propose solving this problem.
This is so powerful, it makes me wonder why they didn't just make a new markdowny syntax for Latex so they could reuse everything from the Latex ecosystem. A bit like what CoffeeScript was for JavaScript, I mean.
That assumes that the only issue with LaTeX is its syntax. Other issues I can think of are that LaTeX doesn't generate HTML and that LaTeX is completely Unicode-disabled.
How do the science and math papers use characters that aren't in... ASCII? Maybe I need to look at an ASCII chart.
Out of curiosity, isn't UTF implementation much easier now than it has been? I piddle in writing things and I rarely contemplate UTF. Once I tried to reverse engineer an encryption plugin that used Asiatic characters as the ciphertext, and I wanted to use emoji, and that was when I learned I am too dumb to understand utf. But there's libiconv, which I first saw in production (ICQ or aim or Trillian or so) over 22 years ago, personally.
So is the latex thing obstinance, technical, or political?
Sorry you need to catch up! The latest LaTeX engines (LuaLaTeX) can even do unicode math! But yes the Unicode spec s not something one can understand in a few hours.
Other incorrect statement is that LaTeX cannot generate HTML. There is number of projects for LaTeX to HTML conversion (TeX4ht, Lwarp, LaTeXML), also Pandoc can convert subset of LaTeX to HTML.
I'm confused. Your first sentence implies that LaTeX can generate HTML and then you process to list other projects that you need. This whole thread is about an alternative to LaTeX which can actually genuinely just output HTML.
Absolutely; One should also keep in mind why do you need the HTML, drop the pdf file on Google drive, and it will serve it fine, no webservers can limit who can see it, no friction for authorizations etc. Granted difficult to view on a mobile, but who can really do serious reading of a paper on mobile?
OK so either you're confirming that LaTeX is useless for anyone who actually needs to generate HTML and not PDF, or you're implying that nobody ever needs to use HTML and the whole Internet should just be PDFs?
I've recently started rewriting basic process documentation into markdown, which also needs to be printed with a simple header and footer. I found that rendering to html, adding pagedjs cdn, and adding a styled header & footer tags looks and prints great already.
It's surprising how close html & css are to being a pretty good layout system.
I want to move on from LaTeX syntax as much as the next person (hard to read, etc.),
But as a consumer/user, wouldn't a more uniform syntax (large adoption of Typst, etc) be preferable to having multiple different typesetting systems. I feel like the prevailing aspect of LaTeX is its universality?
Any reason to not just use Pandoc? It's been 15 years since I ran into this problem, but even at that point Pandoc made it pretty easy to go from Markdown -> Latex and then render from Latex -> PDF. The benefit of this pipeline is that if I needed to fine tune any of the Latex there was flexibility to do so.
I have been generating documents for a while using https://github.com/enhuiz/eisvogel. It's nice to use markdown, but I feel really limited, and can't do much customization.
Some things I would want to see in a typesetting system:
- Having a typesetting quality and control like TeX does, including mathematical typesetting, although improvements could be made to that, too. (I think I would also like the syntax more like TeX has)
- You can include PostScript codes within the document which can run during the typesetting process (rather than only during output), therefore allowing it to affect decisions of page breaks, etc, as well as allowing PostScript to draw diagrams and control text rendering. (I had written a PostScript program to load PK fonts, so that would make it possible to use PK fonts from TeX as well.)
- Full support for non-Unicode text (without converting it internally to Unicode). (It is OK if it also supports Unicode as long as the code to support Unicode is avoided when not using it (in the entire document or in a part of it).)
I think Unicode is messy and is not the best way to do i18n and m17n and l10n and a11y and many other things (although there are also problems with existing implementations that do not have to do with the character set, the character set is one of the problems), and I also think that it is not good to insist on using one character set for everything (especially if that character set is Unicode).
UTF-8, UTF-16, UTF-32, UTF-EBCDIC, etc are encodings of Unicode. EUC-JP is not an encoding of a subset of Unicode; it is an encoding of JIS, which is a different character set. The PC character set is not a subset of Unicode; it is the PC character set. Being able to be mapped to Unicode in some cases does not make it Unicode (nor does it mean that these mappings are necessarily "clean", but even if they are, that still wouldn't make non-Unicode character sets to be (subsets of, or even supersets of) Unicode).
Agreed, it's about _imperative_ vs _declarative_ languages.
The problem with languages like LaTeX etc. is they treat a document as a linear sequence of instructions: "write this text", "switch to justify right" etc. - I think that made sense when LaTeX was created, but publishing has come a long way and imperative thinking doesn't help.
A declarative form of document is the way forward. HTML is -kind of- like that, but unfortunately the assumption that a document is a linear list of stuff is still in there. That's one reason it doesn't work well for print.
Looks amazing of course, but usually it is the nitty gritty details where the mess and headache begins. How can I be confident that this is a viable alternative to fully fledged and mature alternatives like LaTeX?
I felt the same way, though once I scrolled down to the LaTeX comparison it was more obvious. The first few code examples being how you define a function don't lend themselves to showcasing how markdown-esque the actual usage is.
I've started using presenterm for markdown presentations. Given that markdown is just a format, a comprehensive comparison should find the tools using markdown to export to pdf and epub.
EDIT: I was just teasing, probably inappropriately my apologies. I use org-mode -> LaTeX for a similar markdown to article flow. I think it's a good idea and the results look nice.
If the LLM's are starting to output Quarkdown by default - even just one provider (like OpenAI), this will catch on like wildfire. The limitations of Markdown is getting a bit old.
Maybe look at Quarto? Almost every project I start now begins with `quarto project create`. From there I can pivot the material into HTML, .docx, PDF, .PPTX, Typst, LaTeX, and all of them simultaneously.
VSCode and RStudio Desktop both have visual editor components, although they are not perfect. Positron is another editor that is data science specific built on top of VSCode that has Quarto rendering support.
There isn't an 'on-the-fly' rendering component for Quarto per se, but using the preview mode it will re-render a preview watching for file changes. A nice GUI editor for Quarto is definitely something people have been asking for. Closest equivalent would probably be Overleaf or Typst web editors?
HN is fickle, it'll revert, faster if you don't mention it.
I have a couple of "proprietary" pipelines that I'd love to replace, and this also gave me an idea.
For instance when I want to publish a screenshot from windows to my fediverse homeserver, I want it to be as few kilobytes as possible, as I've run a homeserver and the storage needs are obnoxious, so I do my part. Windows takes massive screenshots, embarrassing even by windows 95 bitmap screenshot standards. So win+shift+s, crop selection, win - ms <enter>, shift+insert, ctrl+shift+x, file->save as JPEG, name, enter.
As few as three years ago if I cropped right I could paste the clipboard JPEG and all was well. It doesn't take me long but every time I do it I get three more grey hairs. And I take a lot of screenshots. 2,209 in my screenshot folder. did you know windows saves all your screenshots? they used to be ephemeral.
anyhow i have a bunch of screwy things similar to but not as "simple" as that example. Audio work, text work, data manipulation.
There's plenty of of "proper" markup languages and full programming languages to actually write code in.
Why do we need a hybrid program like this, which is not as simple as pure markup, and is not as powerful as a proper templating language?
I personally just run markdown -> HTML/CSS -> python templating (Jinja or something) -> PDF/HTML
As a dev, I find this works the best for me. But I also cannot imagine that learning Quarkdown would improve my workflow meaningfully, and I also cannot imagine recommending someone learn such a niche product instead of having them learn HTML/CSS and Python (Jinja if they need fancy). Seems like a comparable amount of effort.
Every conference has their own required LaTeX style file that must be used. Unless there is an automated way to convert these exactly, I don't see how LaTeX alternatives can be used.
CS strongly prefers LaTeX [0,1] while broader journals and conferences prefer MS Word over it [2,3]. As long as there is not a solid infrastructure for these other typesetting systems, I never saw the appeal. I think for internal company reports they do have their uses, but other than that, why not use the LaTeX or Word? Realistically any person wanting to submit a work will know how to work with either one or the other.
I also don't see the need for journals and conferences to make a typst template for exactly these reasons. The templates will have to be community-made and then you still run the risk of having a paper rejected a year from now because the template is outdated.
I'm just saying that these systems don't work for me. I write ML/AI conference papers in LaTeX, and I think that use case will be tough to dislodge. I can see this being very attractive to people making other types of documents without a fixed format, especially if you don't already know LaTeX.
Depends on the user. Basic LaTeX2e/LuaTeX can be learned over 5 days. Guru level like any programming language needs its 10K hours. There are people who have an aversion for backlashes. The main reason for the "\" is perhaps the only char that is not commonly found in texts. Others like ":" re very common in texts. When parsing LaTeX and behind it is Knuth's original TeX engine, the commands are swimming in a sea of text (as the Dragon book says).
One thing that has helped with ease of use is Overleaf. It is a hosted LaTeX editor with lots of collaboration features (leaving comments, history of edits) that let people collaborate in real time on a paper. It comes with many templates to get you started on a new document. If you're working with collaborators, it has a lock on the market.
LaTeX itself can be easy for simple things (pick a template, and put text in each section). And it can grow into almost anything if you put in enough effort. It is far and away the standard way to write math equations, so if your document has lots of formulas, that's a plus.
I settled using latex with tectonic, you could always leverage playwright or similar for easy html -> print to pdf without any weird libs? (not great startup time, but you can batch many ops in one session)
# justfile ── put in repo root
set shell := ["bash", "-cu"] # one shell → predictable env, pipe-fail, etc.
# Build a PDF once
pdf:
tectonic -X compile src-v0.1/main.tex --outdir target/pdf # or swap for typst
If one just chooses a reasonable documentclass and if need be a few packages suited to the requirements of one's document, then it all "just works" with (mostly) sensible defaults and minimal configuration.
Memoir hugely simplified my own work in LaTeX back when I was doing book composition.
Well, you'll have to install and keep those packages somewhere on your system. And maybe a few months from now after your latex distribution got updated by the system your document suddenly no longer compiles.
What I want is something like npm-like package management for this, where the packages are just kept there next to the document. I don't care if I'll have a package 20 times on my system either, storage hasn't been a concern in many years.
> And maybe a few months from now after your latex distribution got updated by the system your document suddenly no longer compiles.
I'm using LaTeX 2e for 25+ years. This has literally never happened to me. If that's not stability, I don't know what is. LaTeX documents I wrote in my grad days still compile for me. I just checked and it does. I do keep the dependency packages myself in my folder.
Has this issue ever happened to anyone? Why would LaTeX distribution getting updated break my documents? It's still the same latex compiler and the same base styles and packages!
It happened to me because I had to use the templates and document classes provided by my university, which themselves rely on a bunch of packages I wouldn't have installed myself.
My next step was to just try doing the build in containers but I even ran into it there once because I accidentally pulled a newer image...
But it's just anecdotally. Maybe I really was holding it all wrong.
The only instance of a document not working right anymore for me was a really hacked book using an early/beta version of memoir --- there were (documented) breaking changes for the final release --- updated to match the new macro calls and it was back to working in short order.
Is there any specific issue you face which stops you from compiling old files?
As I mentioned in my other comment, my grad school days documents are still compiling fine.
If you still use LaTeX 2e and you've got all the dependency packages with you, pdflatex should Just Work. right? I can't remember any major change that would outright break your compilation. And I haven't seen such issue too myself. So I genuinely want to know what specific issues you or others face that wouldn't even let you compile your document.
> If one just chooses a reasonable documentclass and if need be a few packages suited to the requirements of one's document, then it all "just works" with (mostly) sensible defaults and minimal configuration.
Ironically, very similar to the story with modern C++. If you use a limited subset it can "just work" but only if you are disciplined and don't have to mix in legacy code that's pre-C++11.
which is ironic considering at one time the appeal of LaTeX was "sane defaults". Don't get me wrong. The default choices were really the best choice at some point in the past. They just no longer are.
And latex is one of very few programs where changing defaults would fundamentally undermine its very purpose (being able to recreate documents no matter how old)
This was true maybe 20 years ago, before TeX engines that output directly to PDF were created. Today, the recommended engine is LuaLaTeX, and it defaults to OpenType fonts.
That's why these things don't go anywhere. If I need to write formatting details, it is better to use LaTeX which is a well-tested and stable language that will last for another 30 years.
Outdated means there is something better that is now used to substitute an old technology, which is not the case for Latex. Unfortunately, programmers tend to think "outdated" just means "was created more than 5 years ago"...
Could definitely see using this for docs. We end up with HTML scattered through our markdown files whenever we need something beyond basic formatting, which is ugly. The ecosystem support is the real question though - Markdown works everywhere because it's been around forever.
My FOSS text editor, KeenWrite[1], takes a similar approach: Markdown -> XHTML -> TeX -> PDF. The software architecture shows how you can have processor chains:
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/docs/ima...
I developed KeenWrite to help write a sci-fi novel where I can use variables for character names, places, etc. See the tutorials[2] for details.
For anyone still using pandoc and shell scripts, my Typesetting Markdown[3] series describes building a script-based infrastructure for converting Markdown into PDF.
[1]: https://keenwrite.com/
[2]: https://www.youtube.com/watch?v=CFCqe3A5dFg&t=15s
[3]: https://dave.autonoma.ca/blog/2019/05/22/typesetting-markdow...
I was really excited when I read your post. I've long looked for a good MarkDown -> PDF or RTF workflow, so I gave KeenWrite a quick try. At first glance I really thought I'd be exactly the user for this tool, but quickly realized that the discoverability of KeenWrite isn't nearly good enough.
Upon launch, I'm presented with three panes. I've got a MarkDown authoring interface and an output preview. Great. I drop in some markdown and it renders.
Then I have a "variables.yaml" pane open with three little controls, "Create", "Rename", and "Delete". Ok... I'm editing a YAML file. But it's a clunky nested node editor. People can edit a MarkDown file but you don't think it's faster to simply let people edit YAML in text?
So, I get it, I'm editing a YAML file that stores metadata about... SOMETHING about my document output. Except I don't have a single example of a variable. Not a single one. I have no idea what variables are available and exploring every single menu option tells me nothing. Help only provides a small about page with no link to the documentation.
So, I go to keenwrite.com and click documentation. It takes me to a single GitLab readme that talks about different command line launch options, and then finally how to begin to use metadata, but the options all revolve around creating an .Rmd file and using R or creating a "definitions.yaml" instead of a "variables.yaml" in a seperate editor.
This is the moment I realize there's no chance this tool is going to be useful for me.
Thanks for giving it a try!
> I have no idea what variables are available
Were the video tutorials[0], in particular the variables tutorial[1] not helpful?
> Except I don't have a single example of a variable.
Did you watch the metadata tutorial[2]?
> People can edit a MarkDown file but you don't think it's faster to simply let people edit YAML in text?
Close the variable editor panel if you like and edit the variables in a different text editor. (Or create a symbolic link between the .yaml and .yaml.txt file and edit the .yaml.txt file in a KeenWrite tab.) The downside is that KeenWrite won't know how to inject variables into the document when pressing the Control-Space hotkey.
The variables, architecturally speaking, need not be written in YAML. They could be TOML, XML, JSON, etc. The software reads a nested hierarchy of variables and values into a tree data structure, which abstracts away the data's file format. Presently only YAML format is integrated. The hierarchy is then presented through a clunky JavaFX Tree UI element.
> discoverability of KeenWrite isn't nearly good enough
I received that same feedback years ago and made video tutorials, which are linked to at the bottom of the home page[3]. Do they need to be more prominent?
The home page also links to a documentation page[4] that describes variables, metadata, R integration, and more.
[0]: https://www.youtube.com/playlist?list=PLB-WIt1cZYLm1MMx2FBG9...
[1]: https://youtu.be/CFCqe3A5dFg?&t=11
[2]: https://youtu.be/cjQ-dle-tAE?t=11
[3]: https://keenwrite.com/
[4]: https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/docs/REA...
For me, the issue is not document conversion and is content de-duplication. Product A and Product B manual will share number of sections. Any spelling or grammar error must be updated in Product A and B manuals. They man share the same additions.
So far LaTex has been the only solution to allow binding shared sections into multiple document builds. These are for internal and customer facing information. Only binding duplication is in the revision overview sections pertaining to each document build.
> So far LaTex has been the only solution to allow binding shared sections
R, being a Turing-complete language, can do this. If R Markdown can do it then KeenWrite and pandoc+knitr support it. R can also do conditional includes. For Product A and B to share authentication steps, this could look like:
Where TeX may resemble: SGML, DocBook, AsciiDoc, RST, and other text formats have similar abilities.Would be interesting to see a compare and contrast between this and Typst, which has gotten a lot of attention recently.
Kinda surprising that it isn't mentioned in their feature comparison matrix at all.
Looking at the "mock" document (https://github.com/iamgio/quarkdown/tree/main/mock) which is supposed to be a comprehensive and detailed guide for all visual elements, I don't see ways of getting anything other than basic markdown tables. How do you get merged cells? Cell formatting? Typst has some nice ways of implementing sophisticated grids and tables.
Also how do you implement things like different page numbering for front matter content and the main content? In general, the "simplicity" of markdown seems to be taking away a lot of granular control that people use LaTeX and Typst for.
Last I checked Typst can't emit HTML.
They do now, experimentally. The support is getting improved a lot currently.
It works really well, I've written three blog posts using typst.
Post: https://ezb.io/thoughts/interaction_nets/lambda_calculus/202...
Typst source: https://github.com/enricozb/enricozb.github.io/blob/master/t...
That Typst source looks really clean. I may go back to look into its HTML support.
Thanks for sharing!
Thanks! The main thing that I had difficulty with, which you can see from the typst source, is the rendering and spacing around inline math symbols. They are rendered as SVGs, which is fine but then copying them doesn't work. Their spacing is sometimes unpredictable so I'll add something like $thick x + y$ to pad on the left hand side. I'm not sure what parts of the math symbol contribute to the dimensions of the SVG and I'm sure it's rather complex, but other than that the experience has been solid.
Looks like typst has a "programming language" to do diagrams inline... that's a lot of effort to learn!
It's very much worth it, but absolutely not necessary. You can always generate images/figures beforehand and include them in Typst. There are also packages for various styles of diagrams, e.g. diagraph ships with a Graphviz renderer.
There is also CeTZ, which this article uses. It is highly inspired by TikZ and is just as powerful.
> There is also CeTZ, which this article uses. It is highly inspired by TikZ and is just as powerful.
It's definitely not "just as powerful", and will likely not be so for years. TikZ is an absolutely monumental work.
I've also heard that pandoc now supports typst, and will turn typst format files into html, independent of typst's own code. Have not confirmed.
That's really cool! Would love to create my website with that and also make it available as a pdf for easy archival.
https://typst.app/docs/reference/html/
It is mentioned now. Btw, it looks very similar to.
Is the comparison table accurate? - https://github.com/iamgio/quarkdown#comparison
Surely LaTeX has full scripting ability even though I wouldn't wish such a punishment on anyone.
Surely Quarkdown's gibberish like syntax is not more concise and more readable than Typst?
And surely the learning curve is not easier than Typst? I'd say the learning curve is more or less the same as Typst.
Surely LaTeX can also produce HTML with tex4ht?
>And surely the learning curve is not easier than Typst?
To be fair, (most) markdown is valid Quarkdown. Barrier to entry really doesnt get any lower than that. Of course the learning curve is not fully synonymous with the barrier to entry, but it's a significant part.
And "learning curve" is really such a subjective quality. Kinda fucked from the start once you put it in a comparison table. Explicit features are more objective but even then sometimes products dont NEED certain features because of their design.
Pandoc is your friend for this and many other use cases.
Not sure I understand. I never said anything about my use cases. I was checking the accuracy of the comparison table. Did you mean to post that comment here or were you replying to another comment?
they were probably mentioning that, with pandoc, you can convert between HTML and PDF for any of these tools anyway
Ah! Thanks. Yeah Pandoc is great for conversions to HTML and PDF. It's my no. 1 tool for writing docs and generating multiple formats out of the docs.
I mean one can take a quick look at what has been accomplished in TikZ and pgf to figure LaTeX and plain TeX's scripting ability.
The comparison table is clearly inaccurate.
How is this different from Quarto [0]? Quite similar in name, same extension, appears the same aims, but at the minute less functionality.
[0] https://quarto.org/
Also let's not forget that Quarto is the spiritual successor of the widely successful R Markdown ecosystem. By the same developers: https://quarto.org/docs/faq/#who-are-the-developers-of-quart...
Not just the spiritual successor but also backwards compatible in that Quarto can render R Markdown files (in addition to the newer quarto .qmd spec).
I guess that the similarity of the names come from different places, and in this case might be a remembrance of QuarkXPress. It's convergent evolution! :D
Yeah that's the immediate connection I got too.
I like the syntax.
I guessed the name derived as follows: Quarks as the smallest particles, a view in most detail, the building blocks of things. Typesetting as the lowest level of abstraction for creating a document, "down" from Markdown.
People may not know it but at some point in the nineties you'd enter a bookstore and 95%+ of all the books and magazines were typeset using QuarkXPress.
Then Adobe's InDesign showed up in 1999 and things began to change.
FWIW I both wrote and typeset books myself (for a traditional publisher): I did most of them using QuarkXPress but I managed to sneak one I made with LaTeX (it was a hard sell to the publisher / printing press guys who were only ever using QuarkXPress). Also I was forced to heavily modify LaTeX templates to match exactly the one the publisher was using with QuarkXPress.
So yup when I read "Quarkdown is a modern Markdown-based typetting system" the first thing I think about is QuarkXPress: great memories of MacOS (8? then 9?, pre OS X for sure) and my Sony Trinitron monitor.
QuarkXpress for typesetting, Photoshop for painting pixels, and Macromedia Freehand for turning scanned drawings into vector graphics.
Was still using these in the early 2000s. Good times.
https://www.simongriffee.com/notebook/american-overseas-scho...
Was going to ask the same question. Was talking to a friend just 2 days ago who redid all his lecture scripts with quarto and embedded the lecture presentations. Looked neat. Also that quarto interacts well with R studio and jupyter notebooks comes as a big plus.
The sample outputs look nice!
But I always hate it when a templating language grows function calls and all of that. Maybe it makes sense in this context, I'm not sure.
But if you end up using it together with another language, maybe for server side rendering or some kind of document from data generation, you quickly realize that switching between the two languages wastes a lot of time, and the templating language is never as powerful as the "real" language. So I prefer JSX, or something like Javascript's tagged template literals. Something where you use a real programming language, but where the context of the document is understood, so you don't have to worry about escaping or XSS.
This, Typst, etc etc are primarily typesetting systems for papers.
I would love alternatives to HTML or whatever, but I tried Typst too and it's very clear that the authors only really care about typesetting for papers and other long form prose. Stuff like forms, invoices, flyers, handouts, leaflets, business cards -- an afterthought, at best.
Edit: Actually I was thinking of Sile not Typst, but I think the same applies to Typst too. I didn't dig into Typst too much because it was commercial though.
> Stuff like forms, invoices, flyers, handouts, leaflets, business cards -- an afterthought, at best.
It is because you can typeset beautiful long text algorithmically and all these small forms like invoices and flyers are more graphical design than typesetting: you need to place many small elements precisely, not relative to each other but to the edges of the page / optical centers / etc. It is not very convenient without WYSIWYG. Possible, yes, but will require many trial-and-error when in WYSIWYG layout program can be done from first try.
Think about tabloids too: text, which wraps around non-rectangualr images, cut-outs, etc. Hard to do without seeing what you do, only with text and coordinates.
Edit: typo test → text.
I don't agree. Plenty of people write HTML by hand, no WYSIWYG, often with no more than a live preview pane like Typst's.
Why isn't it easy to place something relative to the edges of a page via text? In HTML I do `padding: 2cm` and I'm done. I'd say most of design involves placing elements relative to eachother; half the constraints in GUI design tools are matching spacing or aligning to nearby elements.
I'm not saying you can do the whole thing blind, but for the odd thing that does need visual feedback, not having a convenient UI isn't a critical failure. Some of those things are hard to do in a GUI too, and having a good text based layout tool could be easier.
On the other hand, all "official-looking" documents like invoices (with complex headers and footers) I seen in HTML was ungodly mess of nested tables, not something clean and structured.
I don't say it is impossible. But looks like it is hard.
Is there any reason why you can't use Typst for any of the stuff you mentioned? I can't see why you couldn't (except for interactive forms, which is already being worked on [1]. The pdf-writer low-level backend seems to have already implemented support for form fields, so it seems like a matter of time until it is implemented in Typst).
[1] https://github.com/typst/typst/issues/1765
You definitely can, I designed a 206x85cm standing banner for my last trade show as one of the first "production" things I built in Typst:
https://typst.app/project/r1YNDcKpoF1sVXHf5n4VKB
Plus you can share the rendered and preview form of the project with a single link, which is pretty neat.
I believe you can do those sorts of layouts in Typst (and Latex, and Sile!), but it's about how far out of the way you have to go and how much you fight the system in the process. I don't see any examples of Typst doing anything other than papers, I believe for good reason.
To be clear, I mean from a design perspective. Like take a print copy of Wired... how hard would it be to replicate any of those pages? Without using other software (aside from maybe cutting up stock photos). I can format scientific papers in HTML and it's not too hard, I can also format a cookbook, and it's not that hard. It's not great either!
I found it much easier to use Typst to create any of these documents than any other software I used before. Just loading data from a JSON and incrementally regenerating the document on each change is game-changing for me.
Honestly, I don't think that it would be too hard. With the grid function you can do a lot of things, specially because you can use grid.cell(rowspan:3, colswap:4) to make cells that span multiple rows or columns, use fractional sizes for the columns (1fr, 2fr, etc), and add independent insets and strokes for each cell, so you can already do a lot of the things you can achieve with css flexbox.
Though I suppose the docs could include tutorials for how to use them to make a more diverse kind of documents, and adding another layout function that behaves more like flexbox would be nice (though it wouldn't be too hard to create a function that re-creates the behaviour of flexbox based on the grid function).
The online editor is commercial. They have a github repository releasing Typst under an Apache 2.0 license for free. I installed it using cargo (Rust), and don't use the online editor.
Oh, I didn't realize that! I can't shake the feeling that the open source community engagement might cater to paying customers, but I'll need to take a closer look!
You can use typst locally and bypass the commercial bits. It is really easy to create different kinds of documents with it. I have been using it to create slides and handouts, and for that I already find it much easier to use than the alternatives.
Can you make slides and handouts from the same primary document? That'd save me an inordinate amount of time for some church use-cases.
Look at Quarto. Markdown input, basically any output you want, including HTML, PDF, DOCX, PPTX, etc... All from the same input. Reuse text chunks, use variables, templates, and more. Then just run 'quarto render'.
Thanks!
My first "real" usecase for Typst was a poster [0], since it was much easier than doing it in LaTeX. It's missing some features, like wrapping around figures and flowing text between boxes, but TeX doesn't have the second either and both are planned in Typst.
[0]: https://dvdkon.ggu.cz/projects/pppql/poster.pdf
Flowing text between boxes can be done with flowfram, which is old and clunky, but works OK.
I might be using Typst wrong, but it's like a visual programming environment. I guess I found my jsfiddle or other tools that other people use.
It's very satisfying to play with visualizations in Typst, especially since it updates the output so fast (instant for small projects).
You may be familiar already, but does paged.js fit your bill?
[0]: https://github.com/pagedjs/pagedjs
That looks interesting, and to be fair right now I'm doing something similar... but doing headless rendering with that sort of stuff is very hard, AFAIK the standard tool for that has been abandoned now for a couple years. Also there are other issues with browsers, like creating CMYK PDFs.
This just looks like reStructuredText.
Quarkdown:
rST:Since 70% of comments under each of these posts are always "why not LaTeX?!", I want to start by reaffirming: yes, I do want a modern Markdown-based typesetting system. There even is a place of several of them. It would be absolutely nice to replace LaTeX, simply because it's old trash with remarkably inconvenient syntax, so, yes, a system with full control over markup is desirable. And if it necessarily increases verbosity, then there absolutely is a place for something "just a touch more powerful than markdown".
However, at a glance it doesn't strike me as what I was looking for. There aren't too many examples, but it seems like it leans heavier towards "just a touch more powerful than markdown" rather than to "replace LaTeX" (or Typst, for that matter). And for the first scenario to play out, it must be really seamless to use. This one doesn't seem to be.
1. Just to take care of the elephant in the room: JVM. Same as many others, I won't even bother installing it to try it out, so it doesn't help virality much.
2. I don't like the syntax. It needs to be as compatible with plain markdown as possible, and this one isn't quite. My main issue is with argument to a function being tabulated. It seems like it will lead to the whole document being tabulated. It is a natural for markdown-compatible add-ons to employ a code/monospace blocks, but ```plugin-name is a better way to do it, because it doesn't mean you have to reformat your whole document when you decide to step off from plain markdown.
3. Since a "better markdown" is something more suitable for something that starts as your personal notes (if you are specifically working on preparing a document for publishing, indeed you can just do it in LaTeX as well), I suppose it's only useful to an extent it is integrated into your notetaking app. Surely, there are still some people who do it in Emacs or Vim, but even such a retrograde as myself eventually moved on to Obsidian. I want ways to control my document structure better inside my notetaking app with a potential ability to publish. But as a standalone thing, I'm not sure why would I use it. At least Typst has a proprietary online editor. I suppose, that's also how nearly everyone uses it.
LaTeX is not "old trash". It's one of the best piece of software ever written. Just don't import bs in your document.
I’d argue that Typst probably beats it on all levels. Have you ever seen a LaTeX document? (The question is rhetorical, of course you have) Just because it was the best thing before doesn’t mean it still is now. I’d say the only thing it still has going for it is momentum.
I looked at the Typst documentation and from what I could tell, it has 3 hard-coded "Modes" for 3 hard-coded kinds of syntax (normal, math, code). I couldn't find any way to add any custom syntax - is there a way to do this?
Tex/LaTeX are completely syntactically extensible. For example, a logician might want to use the software with any number of their notations, or a physicist drawing Feynmann diagrams, etc. I think at one point Lillypad used it for typesetting sheet music.
Edit: i found it! https://typst.app/docs/guides/guide-for-latex-users/#package...
Inside certain boundaries, you can define custom markup syntax in a way, including abbreviations or more scary regex matching style rules.
But code syntax can not be changed an no you can't redefine if @ is a letter or not and flip flop that in your code like latex does.
I hated most Latex syntactic extensions that I ever has to deal with. They basically force you to learn completly different languages, each with their own quirks. I found simple function-looking macros to most often be more intuitive and reliable.
Markdown, Quardown, Typst, this and that. This looks to LaTeX. All of this became so confusing and un-standardized - I went back to HTML+CSS.
You know what, while you're at it, I might as well bring it up. How about XML?
I haven't really tried writing large pieces of text in it but I am already seriously considering. All other alternatives are too complicated and have a learning curve that gets in the way of writing itself. With XML, I'd be able to define my own tags and run them by a parser later on to auto-generate indexable footnotes, and create my own ways of structuring text besides the usual ones (chapters, sections, etcetera). Has anyone tried this approach?
Professional tech writer here: We use GitHub and a tool called OxygenXML to write docs-as-code in an XML DTD called "DITA". It's a hefty IBM invention from the early aughts, but it covers every use case I've thrown at it, from small documentation sets to multi-thousand-page monsters. Supports PDF, HTML, Word, and many other output types.
DITA's so great at everything _except contributions from non-tech writers_ that half of my career has involved migrating tech writing stacks that use it to Markdown/SSGs in git repos.
DITA's benefits require a certain scale that most tech companies never achieve. And the Open Toolkit is a nightmare piece of software.
Agreed, and we use Markdown where we can. But inevitably some product manager comes along and demands tables inside tables or embedded reuse of content... and it's back to DITA.
OxygenXML makes the OT much more manageable. I haven't had to touch an OT XSL transform in a few years now. Worth every penny.
Basically DocBook?
Exactly. Seems like we already invented that but it didn’t really catch fire.
Yeah last time I touched it was during an internship 15 years ago, the few memories I recall were not enjoyment at all (however I was using LaTeX everywhere at the time).
Writing documentation as XML is powerful but not enjoyable at all I guess
I have been thinking about this seriously myself. Not with a specific existing schema like DocBook, but with a custom schema (defined by me) that I then compile to standard schemas, like DocBook or HTML.
This seems extensible to the degree that I want (i.e. semantically rich enough that you can conceivably hang any application from it). But I just can't bring myself to write in XML syntax, especially for maths.
There's also a standard to turn XML into HTML via XSLT.
Well basic markdown is super useful to do stuff quickly.
Problem is when people started to build systems upon systems upon something that should not be used for more complicated cases.
Maybe not a problem because I don't care but I just see how loads of things that someone created to be "just that" someone takes without understanding and builds on top instead of understanding limitations and scope of the initial idea or system.
It is "oh it is missing a feature" - where it is "no it wasn't built to do that".
I have seen notepad in windows shipping some formatting features, I don't see that as an improvement. Notepad was notepad for purpose.
I think a good balance for a markdown syntax is something you can write nearly naturally on the fly (very low syntax needed for basic use) but can continue to mark up in more detail when you want to turn something into a complex use case (very high syntax ceiling for the complex cases). HTML+CSS almost gets there except the tags are a bit awkward for simple things like just <strong>bolding</strong> a word.
Regarding Notepad, keep in mind they dumped an entire separate app (WordPad) by merging the ability to format into Notepad. This kind of mirrors what I was talking about above: one app with a very low floor but a flexibly high ceiling when you want to go there with it rather than two separate apps you need to pick from up front.
There’s also the mature and reliable Org-mode, if you don’t mind Emacs as an editor.
Does org-mode have a spec? From what I've seen, org-mode is defined as whatever Emacs does. Without a spec I can't see how it's a viable format for widespread usage.
Org-mode has all three of:
1. Spec, written after the fact, not by a core dev.
2. Live help in 'org-info'.
3. Elisp string extraction via 'M-x describe-function' and the like.
Difficulties arise from subtle inconsistencies between the three, and inability of any one to comprehend the kitchen-tool-bin jumble of low- and high-level functionality that has been added over the years.
OTOH, content display is economical of eye and finger effort, and some of the Emacs interaction features startingly powerful.
I wrote my own, use-case specific converter to expand org-format to HTML. Runs on the CL, written in Go.
There is a Neovim "fork" of org mode that defined a spec for their format (which differs somewhat from org mode though)
Same. Replacing elements in with DOM in webdev is surprisingly fun with websockets too.
Having to know and learn 300 clunky frameworks, 97 different syntaxes it gets old.
HTML. CSS. Javascript.
Ask the AI to give me a markdown to html converter, good2go
> Ask the AI to give me a markdown to html converter, good2go
Why would you do that? There are dozens of libraries which do exactly that. Instead of AI you can ask npm or pip, heck you can even ask CRAN[1].
1: https://cran.r-project.org/web/packages/markdown/index.html
Exactly. It tells me the same things. It'll often give me the require() for javascript on packages I should use.
Personally, I don’t see the point. Searching for markdown libraries is not hard, a good library (the same that will show up first) will show you usage instructions at the top. You can copy-paste those and be done.
Also modern JavaScript uses import, require() is very 2015. If the AI is recommending you use require() I would suggest a better one.
If 2005 text editors autocomplete made it easy to balance and indent html/xml tags and syntax highlighting like today, would JSON, Yaml, Markdown have taken off? In The Art of Unix Programming from 2003, the author states editing xml by hand is torture, hence we must invent unique text formats and parsers for the same.
I have not been able to configure an editor that makes it less painful. I think it's not just the verbosity (although that is painful) - the prefix notation makes some things inherently hard to read. MathML is almost impossible.
Ah yes, writing my notes down in css and html. My favorite!
Seriously though, every time some new hotness comes along, you don’t really have to use it or even waste your time looking at it. Markdown will likely be here after all of its derivatives are long gone.
Gruber and Schwarz knew that in simplicity is a beauty.
Basic markdown format is good enough.
For specific cases, it depends what is the outcome - html, pdf…
But hell are binary formats that are used for page layout - vendor lock for centuries. Backward compatibility? Forget about it.
From this point of view people should stick to text based formats. Markdown, LaTex, Typst… you name it. Just use it :)
For me the only addition to markdown I usually enjoy is mathematical typesetting like on GitHub using the inline $$ syntax or the code blocks with the language set to `math`
> What could be mistaken for a planet is actually a quark or, more specifically, a down quark, an elementary particle that is a major constituent of matter: they give life to every complex structure we know of, while also being one of the lightest objects in existence.
Cool project, but seems dangerous to use the word “Quark” in a publishing context RE: QuarkXPress:
- https://tsdr.uspto.gov/#caseNumber=90886976&caseSearchType=U...
- https://tsdr.uspto.gov/#caseNumber=97009034&caseSearchType=U...
(Why do they have two for the same word?)
Does it need more keywords? This syntax reminds me of Smalltalk syntax a little and Smalltalk famously got away with merely 6 keywords. I didn't check the syntax in detail for quarkdown, and I don't expect it to be as well thought out as Smalltalk, but it is quite possible to get away with only few keywords. Question is then how complete their concept is right now. Also there could be a versioning mechanism, that labels a document as for a specific version of Quarkdown.
64kb of ram is enough for anyone.
A backward compatible design would be resolve to user-defined functions first, built-in keywords afterwards.
That way any new keywords won't be a backward incompatible change.
That's a pretty bad design. You don't want users to be able to create functions named as keywords because it will break other code.
if you have a UDF called .until and then this becomes a keyword, does the new 3rd party library you start using that uses the keyword .until still work, and what does the LLM vibe-coded start doing in the future when it makes use of the .until keyword?
I like it for what it is, a layer on top of markdown. That said, the main usage of markdown for me is that it's just the content and it doesn't have any opinions on the layout let alone logic.
I can add those with the use of css/js for web and interpreters and themes for print/non web.
Interested in this! Recently wrote a thesis. Wanted to use markdown, but that had too many limitations.
After learning and using LaTeX for a bit I got used to it, but the overall experience of setting it up and its usability leaves a lot of room for improvements. But on the other hand it's established in academic writing.
Do hope to see something based on markdown be able to replace LaTeX in the future.
With Emacs and AUCTeX and a few macros for tab completion I could generally transcribe a math lecture in real time. If you're using completion then the verbosity isn't a downside and in fact helps add structure for automation.
The main drawback for writing something like a thesis is that LaTeX not great to outline in. I think for my thesis I ended up doing initial drafts in org-mode and exporting into LaTeX to view it.
Then once the overall structure took shape I edited the LaTeX directly. Otherwise you end up having to embed LaTeX markup in your markdown doc because markdown is underspecified compared to TeX.
Quarto is probably what you're looking for. It's what we've been using for scientific publications in gov science research labs the past couple of years. Can output to LaTeX and incorporate templates and such.
Very intriguing. I write my resume in a blend of LaTeX and Markdown, use Pandoc to convert the file to LaTeX, which then gets turned into a PDF. This might be a tidier solution on the front end, though I like my current flow because the maturity of all the tools means I can come back to my resume after several years and it'll still compile.
Very cool, but CLI tools with a JVM language? :( I'd be much quicker to try this out with a static binary.
It was cool until I saw it needs gradlew to build and Java 17+ to be installed.
Hey, something other than Minecraft that requires Java > 16. Maybe just spigot and paperm.
Interesting, but I wonder what does this offer that typst doesn't?
The comparison to LaTeX is a bit unfair... the latex code is much larger than it needs to, and does things that the quarkdown doesn't (like floating the figure in the page).
Once you remove that, both versions look essentially equivalent and just as readable.
If the sea of backslashes and \begin/end and \includegraphics doesn't disappear, no, latex doesn't look equivalent
The words "begin" and "end" are very readable, actually. "includegraphics" as well. Remains the aversion against backslashes. What exactly do you find less readable about them than other symbols like for example the colons or braces in Quarkdown? Or is it about the number of backslashes?
Actually, no, if markup takes more space than content, it hurts readability of the content. Especially for such common stuff like images.
But if you don't see this obvious barrier, I will unlikely be able to explain the issue with backslashes: it's partially about the number, but also visibility - .period syntax is a smart choice as it's unobtrusive and not part of the regular syntax, and it's more ergonomic to type, so a universal win.
I get that people don't like the braces in TeX but ... :-)
I'm only half sarcastic here, I don't like them either. I have recently been using pandoc[1] to do the things they are talking about, I had added some stuff in perl using the Template Toolkit[2] to make HTML pages. My issue is that I have very different fugue states for writing vs. coding. Switching states breaks my flow so I've been trying to make the two modes as orthogonal as possible.
I'm curious if anyone has used something like this to go straight to PNG. My use case is that I have a surplus epaper display that can display pngs it fetches from the network and I've been forwarding it my todo list. Have been doing this with a LuaTeX flow but would like something a bit more seamless.
[1] Pandoc -- https://pandoc.org/
[2] Template Toolkit -- https://template-toolkit.org/
Instead of bolting an engine onto a bicycle to travel long distances, why not just use a motorcycle?
Because muscle-memory is a powerful force, and it's a convenient universal input language.
It's why after years of powershell I still reflexively reach for "ls" not "Get-ChildItem"
( "ls" is aliased by default to Get-ChildItem thankfully! )
Markdown is familiar, easy to use, and very human readable and editable without fear of breaking a compilation step.
Typesetting languages however, TeX, LaTex, postscript or the nightmare of the PDF spec, are not.
If I send someone who doesn't know anything about a document markdown, then there's a good chance they'll be able to make simple edits in their favourite text editor and not screw things up.
If I send someone HTML, they'll likely be able to do simple edits but there's greater risk of breaking elements or styling. Not as bad as with stricter languages, but still significantly more chance than with markdown annotations.
If I send someone some TeX, they'll probably not know what to even do with it, they'll likely get confused and ask for a file format they can use.
Reducing how many different languages we have to master is important, so I think it's great if there's a way to write everything in flavours of markdown.
Write markdown everywhere, and let the backends compile to relevant outputs.
In this instance, it's left perhaps a bit function-heavy so there's still larger "risk", but that's likely something that can be solved through templating.
We have flavours of MD, for github issues, for typesetting, for stackoverflow questions. Slack and Discord have (limited) MD support. We can write blogs in MD through jekyll.
MD is everywhere, it's a convenient universal input language.
What's a good motorcycle for typesetting? Any recommendations?
EasyWriter!
https://en.wikipedia.org/wiki/EasyWriter
https://www.youtube.com/watch?v=4j7zD5ydpUo
Adobe InDesign.
InDesign is awesome. Anyone designing a general purpose document language should spend a lot of time in InDesign first. LaTeX should not be your mental model.
Typst!
I would like to have a compiled demo PDF available for download, along with a direct comparison of the same paper created in LaTeX. I would like to see the differences both on screen and in print.
Typst is missing from comparison
Is this standalone, as in: an actual file format people can use? From their website it looks like it won't work without using their service or hosting something yourself?
Yes, there is a standalone compiler for typst that you can use offline for free. Source code is here https://github.com/typst/typst/
Looks like you can compile files as shown here: https://github.com/typst/typst?tab=readme-ov-file#usage
I was a bit surprised to see Kotlin as the main language (I quite like it, but had to move away from JRE-based anything) I hope it can be built as a native binary...
There is kotlin native these days; so not impossible.
Kotlin is kind of nice for this stuff; which is probably why they picked it. IMHO Kotlin is undervalued as a python replacement; it's pretty convenient for a lot of data processing stuff. And being able to use whatever Java libraries are around is also not a bad thing.
Anyway since it is kotlin, you could use kts (the scripting support). You'd still need a jre and kotlin installed but it would make it easy to invoke from the command line and it would be able to pull in jar file dependencies straight from maven central. There might also be a possible path to build this thing via Graal and package it up as native. Another option is to package everything with docker and call it with a simple shell script. And finally, Kotlin has a native compiler as well but I assume there are too many jvm dependencies to be able to use that.
So, there are a few options here to make using this more convenient.
I personally prefer the dotnet ecosystem so for me f# is the definitive python replacement.
But I am digressing.
I wonder how much control this gives you. For example, drop-caps, kerning, text flow around images, etc.
https://github.com/iamgio/quarkdown/blob/main/mock/textforma...
https://github.com/iamgio/quarkdown/blob/main/mock/images.qm...
"Very little" in terms of the text formatting I guess. But there's no reason they can't improve on that.
Looks kinda like restructuredtext, but with exactly half the dots and 100% more curly braces.
Which is where MyST [0] gets its structural cues. That's another alternative missing from the comparison table of this project, and an interesting one for how much it seems to be going for the science community that loves Jupyter notebooks.
[0] https://mystmd.org/
This looks very interesting and more approachable than Typst.
As some who uses headless chrome to turn html into pdf (for invoices), I have been looking for something simpler and faster.
I tried typst, but it felt messy to me. I wonder if quarkdown offers more streamlined experience
Had a chance to read the wiki/docs deeper. Quarkdown seems to use puppeteer and chrome-print-to-pdf to generate PDF from HTML [1].
So, aside from the more minimal format or Markdown compared to HTML, I don't see much appeal in quarkdown compared to feeding HTML to a headless chrome instance.
But it is a cool project if one wants to turn a bunch of markdown files to say a book or an article.
[1] https://github.com/iamgio/quarkdown/wiki/pdf-export
WEasyPrint is great for generating invoices from html!
https://weasyprint.org/
Also the only good implementation of web layout/rendering I've seen done in python.
Whats the difference between them and running a headless chrome docker container?
WEasyPrint's Github:
> From a technical point of view, WeasyPrint is a visual rendering engine for HTML and CSS that can export to PDF. It aims to support web standards for printing. WeasyPrint is free software made available under a BSD license.
> It is based on various libraries but not on a full rendering engine like WebKit or Gecko. The CSS layout engine is written in Python, designed for pagination, and meant to be easy to hack on.
Cool, not who you replied to but this is a cool idea, another way to archive pages. Gotta compare it to singlefile and headless chrome - I've been looking for a faster way to get a snapshot of a webpage via a chatbot (like in discord or matrix). Used to use Firefox headless, but large pages/slower sites would time out the api.
> I tried typst, but it felt messy to me.
What exactly is messy about Typst?
The syntax feels complicated. Maybe I just don't have enough patience for learning a typesetting syntax (I never worked with Latex before).
On top of that, there is no easy way to create a template. For example, I want an invoice template which I can reuse with different data. Theoretically, I can create a typ file for the template, and define the invoice as a function which I then call from a string with, say, json data. It seems great as web service, but not as a library I can use from, say, Rust.
And the type system is a bit confusing. I can define basic types like numbers or string, but when it comes to structs, they don't seem to have support for that.
I find it easier to create a handlebars template, and feed the HTML to headless chrome printing service, which will output a PDF for me. It's not scalable for high volume, but good enough for my needs (takes about 2-3 seconds to generate PDF).
> On top of that, there is no easy way to create a template
Templates are just functions [0].
I think much of the frustration comes from typesetting being a harder problem than it seems at first. In general a typesetting system tries to abstract away how layout is recomputed depending on content.
Supporting contextual content -- cases where the content depend on other content, e.g. numbered lists, numbered figures, references, etc -- involves iterative rendering. This is evidentidly a complexity sinkhole and having a turing complete script language will bite you back when dealing with it. I recommend reding their documentation about it [1] where they explain how they propose solving this problem.
[0]: https://typst.app/docs/tutorial/making-a-template/
[1]: https://typst.app/docs/reference/context/#compiler-iteration...
This is so powerful, it makes me wonder why they didn't just make a new markdowny syntax for Latex so they could reuse everything from the Latex ecosystem. A bit like what CoffeeScript was for JavaScript, I mean.
That assumes that the only issue with LaTeX is its syntax. Other issues I can think of are that LaTeX doesn't generate HTML and that LaTeX is completely Unicode-disabled.
How do the science and math papers use characters that aren't in... ASCII? Maybe I need to look at an ASCII chart.
Out of curiosity, isn't UTF implementation much easier now than it has been? I piddle in writing things and I rarely contemplate UTF. Once I tried to reverse engineer an encryption plugin that used Asiatic characters as the ciphertext, and I wanted to use emoji, and that was when I learned I am too dumb to understand utf. But there's libiconv, which I first saw in production (ICQ or aim or Trillian or so) over 22 years ago, personally.
So is the latex thing obstinance, technical, or political?
Sorry you need to catch up! The latest LaTeX engines (LuaLaTeX) can even do unicode math! But yes the Unicode spec s not something one can understand in a few hours.
Your statement is not correct, LuaLaTeX can output any unicode character you need and also you can use Lua as well for scripting.
Other incorrect statement is that LaTeX cannot generate HTML. There is number of projects for LaTeX to HTML conversion (TeX4ht, Lwarp, LaTeXML), also Pandoc can convert subset of LaTeX to HTML.
I'm confused. Your first sentence implies that LaTeX can generate HTML and then you process to list other projects that you need. This whole thread is about an alternative to LaTeX which can actually genuinely just output HTML.
Absolutely; One should also keep in mind why do you need the HTML, drop the pdf file on Google drive, and it will serve it fine, no webservers can limit who can see it, no friction for authorizations etc. Granted difficult to view on a mobile, but who can really do serious reading of a paper on mobile?
OK so either you're confirming that LaTeX is useless for anyone who actually needs to generate HTML and not PDF, or you're implying that nobody ever needs to use HTML and the whole Internet should just be PDFs?
I admit I was unclear but I wasn't talking about output.
You'll likely lose a lot of the ecosystem since a lot of stuff wouldn't expect such a syntax.
I've recently started rewriting basic process documentation into markdown, which also needs to be printed with a simple header and footer. I found that rendering to html, adding pagedjs cdn, and adding a styled header & footer tags looks and prints great already.
It's surprising how close html & css are to being a pretty good layout system.
I want to move on from LaTeX syntax as much as the next person (hard to read, etc.),
But as a consumer/user, wouldn't a more uniform syntax (large adoption of Typst, etc) be preferable to having multiple different typesetting systems. I feel like the prevailing aspect of LaTeX is its universality?
(Then again, who hates options).
Pandoc should have been in the comparison table.
Any reason to not just use Pandoc? It's been 15 years since I ran into this problem, but even at that point Pandoc made it pretty easy to go from Markdown -> Latex and then render from Latex -> PDF. The benefit of this pipeline is that if I needed to fine tune any of the Latex there was flexibility to do so.
That's a really interesting project.
I have been generating documents for a while using https://github.com/enhuiz/eisvogel. It's nice to use markdown, but I feel really limited, and can't do much customization.
I would love to see some templates for this.
Slightly related, but for forms: https://forms.md
I can't seem to understand how their syntax is "markdown-like" in any way. All I see is some sort of declarative language surrounded by code.
Totally confused. Lost 10 minutes.
Some things I would want to see in a typesetting system:
- Having a typesetting quality and control like TeX does, including mathematical typesetting, although improvements could be made to that, too. (I think I would also like the syntax more like TeX has)
- You can include PostScript codes within the document which can run during the typesetting process (rather than only during output), therefore allowing it to affect decisions of page breaks, etc, as well as allowing PostScript to draw diagrams and control text rendering. (I had written a PostScript program to load PK fonts, so that would make it possible to use PK fonts from TeX as well.)
- Full support for non-Unicode text (without converting it internally to Unicode). (It is OK if it also supports Unicode as long as the code to support Unicode is avoided when not using it (in the entire document or in a part of it).)
do you have some sort of ethical opposition to unicode?
I think Unicode is messy and is not the best way to do i18n and m17n and l10n and a11y and many other things (although there are also problems with existing implementations that do not have to do with the character set, the character set is one of the problems), and I also think that it is not good to insist on using one character set for everything (especially if that character set is Unicode).
UTF-8, UTF-16, UTF-32, UTF-EBCDIC, etc are encodings of Unicode. EUC-JP is not an encoding of a subset of Unicode; it is an encoding of JIS, which is a different character set. The PC character set is not a subset of Unicode; it is the PC character set. Being able to be mapped to Unicode in some cases does not make it Unicode (nor does it mean that these mappings are necessarily "clean", but even if they are, that still wouldn't make non-Unicode character sets to be (subsets of, or even supersets of) Unicode).
So how does going back to multiple incompatible character sets help anything?
What is "non-Unicode" text exactly?
Text that uses character sets other than Unicode.
I don't like the idea of using programming languages for text formatting because it is unclear how to implement a GUI editor for such format.
Also Markdown is pretty bad format, for example it doesn't even have a specification, lot of ambiguity etc. Avoid it.
Agreed, it's about _imperative_ vs _declarative_ languages.
The problem with languages like LaTeX etc. is they treat a document as a linear sequence of instructions: "write this text", "switch to justify right" etc. - I think that made sense when LaTeX was created, but publishing has come a long way and imperative thinking doesn't help.
A declarative form of document is the way forward. HTML is -kind of- like that, but unfortunately the assumption that a document is a linear list of stuff is still in there. That's one reason it doesn't work well for print.
Looks amazing of course, but usually it is the nitty gritty details where the mess and headache begins. How can I be confident that this is a viable alternative to fully fledged and mature alternatives like LaTeX?
Please add an llms.txt file! https://llmstxt.org/
I'd love to see how far I can take this by giving it to an LLM and asking it to format for me with Quarkdown.
> Converting complex HTML pages with navigation, ads, and JavaScript into LLM-friendly plain text is both difficult and imprecise.
Oh my god. It just occurred to me that LLMs may have a better experience “browsing the internet” than humans do.
That is so tragically depressing.
On the other hand, the requirement of stuff like this and MCP for LLMs might just bring back open APIs and stuff like RSS back to the web at large!
Soon we'll start having a humans.txt format to account for this
https://xkcd.com/927/
This is pretty cool! Could you compare your approach to the one taken in Majsdown?
https://github.com/vittorioromeo/majsdown
My first impression was this looks nothing like Markdown. It looks cool, but hardly resembles anything I've seen in Markdown before.
I felt the same way, though once I scrolled down to the LaTeX comparison it was more obvious. The first few code examples being how you define a function don't lend themselves to showcasing how markdown-esque the actual usage is.
I've started using presenterm for markdown presentations. Given that markdown is just a format, a comprehensive comparison should find the tools using markdown to export to pdf and epub.
Do you know how it compares to marp? I've been using it last year and it's pretty nice. I hadn't heard about presenterm before.
- https://marp.app/
Nice! Any plans for epub?
I made a similar project, but functions are made in js.
https://github.com/pedroth/nabladown.js
What's the rationale behind hand coded typesetting these days, besides the cost of desktop publishing software?
Looks cool - is this "backwards compatible" with Markdown? As in, could a Quarkdown file be legible from a regular Markdown renderer?
very nice and would be cool for scientific publishing, but without the publishers (or community) offering templates it'll never fly
I've achieved something similar by passing markdown into handlebars/ejs first before converting it to html
Are there fexprs too? I.e. lambdas that dont evaluate their arguments eagerly but wait until explicit evaluation?
Give the functions two-letter names and you have looped back to 1970's roff.
No comparison with quarto given.
oh no it's LaTeX with significant white space
EDIT: I was just teasing, probably inappropriately my apologies. I use org-mode -> LaTeX for a similar markdown to article flow. I think it's a good idea and the results look nice.
So it's like Typst but easier to learn? Any other advantages?
Typst gang, unite!
The pendulum swings back...
If the LLM's are starting to output Quarkdown by default - even just one provider (like OpenAI), this will catch on like wildfire. The limitations of Markdown is getting a bit old.
At this point just use Typst/Latex.
I don’t understand what this does that LaTeX does not, and though I haven’t checked I suspect the inverse is not the case
Is very slightly more concise syntax worth it?
I'm very excited to boot up and try this. I may have finally found what I need to replace my rickety pipeline of templates and pandoc conversions.
Maybe look at Quarto? Almost every project I start now begins with `quarto project create`. From there I can pivot the material into HTML, .docx, PDF, .PPTX, Typst, LaTeX, and all of them simultaneously.
I've just looked into this, and as far as I can tell Pandoc is a dependency of Quarto and seems to be where a lot of the magic happens!
Which editor or environment do you use to edit these?
VSCode and RStudio Desktop both have visual editor components, although they are not perfect. Positron is another editor that is data science specific built on top of VSCode that has Quarto rendering support.
There isn't an 'on-the-fly' rendering component for Quarto per se, but using the preview mode it will re-render a preview watching for file changes. A nice GUI editor for Quarto is definitely something people have been asking for. Closest equivalent would probably be Overleaf or Typst web editors?
I keep mine tidy in a docker image and use it on bunch of projects: https://github.com/majkinetor/mm-docs
As a comparison to scripting features of Quarkdown, above uses macros plugin which enables python scripting
Thank you for the inspiration. I'm going to look through this with interest too.
I see somebody else downvoted me: presumably they didn't like my excitement! I appreciate the positivity here.
HN is fickle, it'll revert, faster if you don't mention it.
I have a couple of "proprietary" pipelines that I'd love to replace, and this also gave me an idea.
For instance when I want to publish a screenshot from windows to my fediverse homeserver, I want it to be as few kilobytes as possible, as I've run a homeserver and the storage needs are obnoxious, so I do my part. Windows takes massive screenshots, embarrassing even by windows 95 bitmap screenshot standards. So win+shift+s, crop selection, win - ms <enter>, shift+insert, ctrl+shift+x, file->save as JPEG, name, enter.
As few as three years ago if I cropped right I could paste the clipboard JPEG and all was well. It doesn't take me long but every time I do it I get three more grey hairs. And I take a lot of screenshots. 2,209 in my screenshot folder. did you know windows saves all your screenshots? they used to be ephemeral.
anyhow i have a bunch of screwy things similar to but not as "simple" as that example. Audio work, text work, data manipulation.
You are welcome. If you want to try this system, I will be glad to help onboarding.
Can this compile to LaTeX?
Yes, any alternatives which invented their own syntax which is not markdown is just a waste of everything.
The base markdown is too primitive to use without extensions, so aren't most used markdowns actually invent their own syntax?
Looks good but Typst seems miles ahead.
It lost me here:
> Java 17 or higher is required.
Is this the usual anti-java sentiment or is there something in particular with java >= 17 that you have something against?
It has obvious annoyances like these deeply nested paths:
quarkdown-quarkdoc-reader/src/main/kotlin/com/quarkdown/quarkdoc/reader/dokka/DokkaHtmlContentExtractor.kt
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Not sure if I would be taunting the trademark lawyers of Quark Software like this, but you do you I guess.
Yeah I had similar thoughts, but the name's certainly clever - it made me grin!
I'm not quite sure who this is for.
Markdown is for keeping things simple.
There's plenty of of "proper" markup languages and full programming languages to actually write code in.
Why do we need a hybrid program like this, which is not as simple as pure markup, and is not as powerful as a proper templating language?
I personally just run markdown -> HTML/CSS -> python templating (Jinja or something) -> PDF/HTML
As a dev, I find this works the best for me. But I also cannot imagine that learning Quarkdown would improve my workflow meaningfully, and I also cannot imagine recommending someone learn such a niche product instead of having them learn HTML/CSS and Python (Jinja if they need fancy). Seems like a comparable amount of effort.
This is for academic and publication journals.
Which is why you see Typst it's strongest competitor in the Comparison Chart.
Every conference has their own required LaTeX style file that must be used. Unless there is an automated way to convert these exactly, I don't see how LaTeX alternatives can be used.
I think that might be true at some maths and computer science meetings but is unheard of in other scientific fields.
CS strongly prefers LaTeX [0,1] while broader journals and conferences prefer MS Word over it [2,3]. As long as there is not a solid infrastructure for these other typesetting systems, I never saw the appeal. I think for internal company reports they do have their uses, but other than that, why not use the LaTeX or Word? Realistically any person wanting to submit a work will know how to work with either one or the other.
I also don't see the need for journals and conferences to make a typst template for exactly these reasons. The templates will have to be community-made and then you still run the risk of having a paper rejected a year from now because the template is outdated.
[0] https://conferences.miccai.org/2025/en/PAPER-SUBMISSION-GUID...
[1] https://github.com/apoorvkh/cvpr-latex-template
[2] https://www.nature.com/nature/for-authors/formatting-guide
[3] https://www.science.org/content/page/science-information-aut...
You make a fair point - I'm talking specifically about CS/ML/AI conferences. I shouldn't overgeneralize.
It's the standard in most hard science fields. Also common in some humanities, too.
Can I ask which humanities?
I'm probably showing my bias here, but I'm (respectfully) surprised that, say, poets would want to work in LaTeX :)
Linguistics and many of its subbranches. Historians, archaeologists and to be honest LaTeX is great for poetry.
This is a general argument against any sort of innovation in this field, which is absurd.
I'm just saying that these systems don't work for me. I write ML/AI conference papers in LaTeX, and I think that use case will be tough to dislodge. I can see this being very attractive to people making other types of documents without a fixed format, especially if you don't already know LaTeX.
Is LaTeX difficult to learn? An article stated something about how its syntax is inscrutable, from what memory will allow before the caffeine hits.
It's hell. You usually use an existing layout and adapt it to your needs, but even that can be counter intuitive.
Source : wrote my MLaw papers with it.
What's the problem with making your own layouts? just the syntax?
Depends on the user. Basic LaTeX2e/LuaTeX can be learned over 5 days. Guru level like any programming language needs its 10K hours. There are people who have an aversion for backlashes. The main reason for the "\" is perhaps the only char that is not commonly found in texts. Others like ":" re very common in texts. When parsing LaTeX and behind it is Knuth's original TeX engine, the commands are swimming in a sea of text (as the Dragon book says).
One thing that has helped with ease of use is Overleaf. It is a hosted LaTeX editor with lots of collaboration features (leaving comments, history of edits) that let people collaborate in real time on a paper. It comes with many templates to get you started on a new document. If you're working with collaborators, it has a lock on the market.
LaTeX itself can be easy for simple things (pick a template, and put text in each section). And it can grow into almost anything if you put in enough effort. It is far and away the standard way to write math equations, so if your document has lots of formulas, that's a plus.
llms are great at handling syntax for you so you can focus on your work
I never wrote latex before, but writing a simple PDF / scholarly article from code is pretty easy with current tools if you're a dev
> writing a simple PDF / scholarly article from code is pretty easy with current tools
I tripped over a lot of abandonware while looking for a free OSS HTML->PDF solution, recently. What do you recommend?
I settled using latex with tectonic, you could always leverage playwright or similar for easy html -> print to pdf without any weird libs? (not great startup time, but you can batch many ops in one session)
# justfile ── put in repo root set shell := ["bash", "-cu"] # one shell → predictable env, pipe-fail, etc.
# Build a PDF once pdf: tectonic -X compile src-v0.1/main.tex --outdir target/pdf # or swap for typst
# Clean artefacts clean: rm -rf target
# Live-reload while writing watch: cargo watch -q -x 'just pdf'
then i just split the paper in sections like react components but using tex
main.tex
\documentclass{article}
\input{preamble}
\begin{document} \maketitle
\input{sections/abstract}
\input{sections/introduction}
\input{sections/syntax}
\input{sections/evaluation}
\input{sections/conclusion}
\end{document}
as an academic I don't see myself using this because I don't see my co-authors using this.
Be the change you want to see in the world!
I'll wait until after tenure.
They should have added Quarto there imo.
It's for me, as far as I can tell! I like making PDFs.
My ideas start in Obsidian (Markdown) and then I use pandoc and add a bunch of cursed inline LaTeX hacks to the Markdown for the final product.
I guess cursed hacks are part of any workflow, but I am definitely going to check this out.
its for people who want latex but are mad that latex became c++
If one just chooses a reasonable documentclass and if need be a few packages suited to the requirements of one's document, then it all "just works" with (mostly) sensible defaults and minimal configuration.
Memoir hugely simplified my own work in LaTeX back when I was doing book composition.
Or, just use LyX....
Well, you'll have to install and keep those packages somewhere on your system. And maybe a few months from now after your latex distribution got updated by the system your document suddenly no longer compiles.
What I want is something like npm-like package management for this, where the packages are just kept there next to the document. I don't care if I'll have a package 20 times on my system either, storage hasn't been a concern in many years.
> And maybe a few months from now after your latex distribution got updated by the system your document suddenly no longer compiles.
I'm using LaTeX 2e for 25+ years. This has literally never happened to me. If that's not stability, I don't know what is. LaTeX documents I wrote in my grad days still compile for me. I just checked and it does. I do keep the dependency packages myself in my folder.
Has this issue ever happened to anyone? Why would LaTeX distribution getting updated break my documents? It's still the same latex compiler and the same base styles and packages!
It happened to me because I had to use the templates and document classes provided by my university, which themselves rely on a bunch of packages I wouldn't have installed myself.
My next step was to just try doing the build in containers but I even ran into it there once because I accidentally pulled a newer image...
But it's just anecdotally. Maybe I really was holding it all wrong.
The only instance of a document not working right anymore for me was a really hacked book using an early/beta version of memoir --- there were (documented) breaking changes for the final release --- updated to match the new macro calls and it was back to working in short order.
> I'm using LaTeX 2e for 25+ years
it gets annoying when you use LaTeX once a year for 25 years.
> when you use LaTeX once a year for 25 years
That's me.
Is there any specific issue you face which stops you from compiling old files?
As I mentioned in my other comment, my grad school days documents are still compiling fine.
If you still use LaTeX 2e and you've got all the dependency packages with you, pdflatex should Just Work. right? I can't remember any major change that would outright break your compilation. And I haven't seen such issue too myself. So I genuinely want to know what specific issues you or others face that wouldn't even let you compile your document.
Not trying to argue that this happens regularly, but some recent (last 6 months or so) minted update contained breaking changes.
Maybe running Latex in a container would meet your requirements?
There's a package for that:
https://ctan.org/pkg/collect?lang=en
Write a Nix expression to compile your document. That way you can be sure it keeps working. I did this long ago for my PhD thesis and other papers.
> If one just chooses a reasonable documentclass and if need be a few packages suited to the requirements of one's document, then it all "just works" with (mostly) sensible defaults and minimal configuration.
Ironically, very similar to the story with modern C++. If you use a limited subset it can "just work" but only if you are disciplined and don't have to mix in legacy code that's pre-C++11.
look c++99 was a very cromulent c++ as well. oh lol just like the LaTeX story
LaTeX also has some bizarre defaults like bitmap fonts in a tool designed to allow people to create high quality typeset documents.
which is ironic considering at one time the appeal of LaTeX was "sane defaults". Don't get me wrong. The default choices were really the best choice at some point in the past. They just no longer are.
And latex is one of very few programs where changing defaults would fundamentally undermine its very purpose (being able to recreate documents no matter how old)
This was true maybe 20 years ago, before TeX engines that output directly to PDF were created. Today, the recommended engine is LuaLaTeX, and it defaults to OpenType fonts.
Thanks for updating me. That corresponds with my own timeline where I last tried it 20 years ago.
Became? When? I have latex documents written a couple decades ago that still render fine.
What happens in 10 years to all the Quarkdown documents once this fad fades away?
when this tool has "FakeBold"[0] like Latex has, I'll make the switch.
[0]: https://x.com/OrganicGPT/status/1920202649481236745/photo/1
What does that actually mean? The tweet is not very clear. Is it the bold in the header? What's special about it?
I'm assuming it's emboldening text by thickening up the strokes instead of using a (possibly non-existent) bold variant of the font?
Is there something like that for Typst?
That's why these things don't go anywhere. If I need to write formatting details, it is better to use LaTeX which is a well-tested and stable language that will last for another 30 years.
Plus, with Latex you can use LLMs as assistants and they do a great job thanks to so much Latex data they've seen in training.
And at least I can be sure that any math expression can be written somehow in latex, no mater how bizarre.
Yet also incredible verbose and outdated
Outdated means there is something better that is now used to substitute an old technology, which is not the case for Latex. Unfortunately, programmers tend to think "outdated" just means "was created more than 5 years ago"...
.
Could definitely see using this for docs. We end up with HTML scattered through our markdown files whenever we need something beyond basic formatting, which is ugly. The ecosystem support is the real question though - Markdown works everywhere because it's been around forever.
> I personally just run markdown -> HTML/CSS -> python templating (Jinja or something) -> PDF/HTML
Unix philosophy vs highly integrated vertical Microsoft style applications. One benefits users, the other, the vendor.
>markdown -> HTML/CSS -> python templating (Jinja or something) -> PDF/HTML
Uh...
maybe thats why they just want markdown -> PDF/HTML
Well, but you don't have `markdown -> PDF/HTML`
Also, if you don't need the python bits, you just skip Python :)