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?
As a comparison to scripting features of Quarkdown, above uses macros plugin which enables python scripting
I see somebody else downvoted me: presumably they didn't like my excitement! I appreciate the positivity here.
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 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 like the syntax.
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 still using these in the early 2000s. Good times.
https://www.simongriffee.com/notebook/american-overseas-scho...
I can add those with the use of css/js for web and interpreters and themes for print/non web.
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
What exactly is messy about Typst?
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).
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...
Also the only good implementation of web layout/rendering I've seen done in python.
> 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.
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.
Once you remove that, both versions look essentially equivalent and just as readable.
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 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.
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!
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).
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.
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.
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.
I don't say it is impossible. But looks like it is hard.
It's very satisfying to play with visualizations in Typst, especially since it updates the output so fast (instant for small projects).
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.
Is very slightly more concise syntax worth it?
https://github.com/iamgio/quarkdown/blob/main/mock/images.qm...
.function {greet}
.greet {world} from:{iamgio}
That way any new keywords won't be a backward incompatible change.
> Java 17 or higher is required.
quarkdown-quarkdoc-reader/src/main/kotlin/com/quarkdown/quarkdoc/reader/dokka/DokkaHtmlContentExtractor.kt
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
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.
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 :)
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.
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
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
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.
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.
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?
Writing documentation as XML is powerful but not enjoyable at all I guess
DITA's benefits require a certain scale that most tech companies never achieve. And the Open Toolkit is a nightmare piece of software.
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.
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.
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.
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?
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.
The comparison table is clearly inaccurate.
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.
Memoir hugely simplified my own work in LaTeX back when I was doing book composition.
Or, just use LyX....
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.
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 gets annoying 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.
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.
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.
[0]: https://x.com/OrganicGPT/status/1920202649481236745/photo/1
What happens in 10 years to all the Quarkdown documents once this fad fades away?
Which is why you see Typst it's strongest competitor in the Comparison Chart.
Source : wrote my MLaw papers with it.
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
I tripped over a lot of abandonware while looking for a free OSS HTML->PDF solution, recently. What do you recommend?
# 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}
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'm probably showing my bias here, but I'm (respectfully) surprised that, say, poets would want to work in LaTeX :)
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...
Uh...
maybe thats why they just want markdown -> PDF/HTML
Also, if you don't need the python bits, you just skip Python :)
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.
Unix philosophy vs highly integrated vertical Microsoft style applications. One benefits users, the other, the vendor.
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.
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.
But I am digressing.
Also Markdown is pretty bad format, for example it doesn't even have a specification, lot of ambiguity etc. Avoid it.
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.
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.
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.
Quarkdown:
.somefunction {arg1} {arg2}
Body argument
.. somefunction:: {arg1} {arg2}
Body argumentHowever, 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.
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...
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.
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.
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?)
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.
[2]: https://www.youtube.com/watch?v=CFCqe3A5dFg&t=15s
[3]: https://dave.autonoma.ca/blog/2019/05/22/typesetting-markdow...
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.
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' );`
\input ../common/authentication.tex
- 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).)
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).
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.
It's surprising how close html & css are to being a pretty good layout system.
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).
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/
structural•1d ago
Kinda surprising that it isn't mentioned in their feature comparison matrix at all.
junon•1d ago
divan•1d ago
lblume•1d ago
sureglymop•1d ago
enricozb•1d ago
Post: https://ezb.io/thoughts/interaction_nets/lambda_calculus/202...
Typst source: https://github.com/enricozb/enricozb.github.io/blob/master/t...
anbotero•1d ago
Thanks for sharing!
enricozb•17h ago
breadwinner•23h ago
lblume•21h ago
There is also CeTZ, which this article uses. It is highly inspired by TikZ and is just as powerful.
andrepd•18h ago
It's definitely not "just as powerful", and will likely not be so for years. TikZ is an absolutely monumental work.
blacksqr•1d ago
shark1•1d ago
msravi•21h ago
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.