A New Typst Template for Pandoc (2025) | Hacker News Reader

A New Typst Template for Pandoc (2025)

imaginarytext.ca

120 pointsankitg1233 comments

I have to say having been a diehard latex person I tried out typst a few weeks ago and within a day I was producing beautiful documents with equations that were as nice as Latex and wildly less of a pita to type. I'm going to be using it for all my study notes from now on.

And a couple of docs I converted from latex went from about 10s to compile in latex to 10ms to compile in typst. I didn't think this would be a big deal since my docs aren't that big and I didn't feel like I was waiting long for compile but I'm already much more productive as a result.

Having said all of that, I have no idea why you would want pandoc or markdown involved. Typst (unlike latex) is really no harder than markdown to type, so you should just be using typst rather than markdown if that's what you want. Then you don't need pandoc in the mix at all.

How much of a mental overhead is the switch? My concerns with switching are less flexible tooling, and less libraries. I can't live without amsmath.

Not OP, but I can comment on my anecdotal experience switching.

Typst is great. I had been using Markdown with Pandoc to write a book. I frequently needed to use raw LaTeX commands, and it was mostly OK but I had a few frustrations with my setup. The biggest was time — my Makefile process was taking several (like 10+) seconds to render everything and that was really tedious when I was trying to get TikZ drawings perfect. My other frustrations were floating figures never appearing where I wanted (common complaint, I think) and weird font issues with certain math symbols in code. (I settled on JuliaMono, which was OK but the experience wasn't a happy memory.)

Maybe six months ago I decided to try Typst. I went through the tutorials and made something basic the same day. Got comfortable and eventually pasted my entire book into Typst and started the tedious process of finding and replacing until it compiled. I still occasionally find a \times or something that I missed.

Unlearning backslashes was the hardest thing for me.

The next hardest thing was switching from TikZ to Cetz. Cetz is pretty good, but just like TikZ it takes an investment to learn. I tried to have AI translate my figures and it was not very successful. Someone wrote a webapp that can translate Typst to LaTeX and the reverse. It is a good way to get started on changing figures, but you'll have to clean up its output by hand a lot.

Though I used LUA LaTeX, I never did find any uses for its scripting. With Typst, I use it all the time. Functions are really easy to write. I recently wrote a REPL formatter to show inputs and outputs in code. I'm happy with it and ought to publish it. My only complaint is that all functions are pure functions; there is not a way (that I know of) to share state from one function invocation to the next.

The templates on the Typst universe are pretty OK, but we need more. I will have to change some of the formatting decisions in the book template I'm using.

One thing I've encountered that I could do in LaTeX that I can't (easily) do in Typst is labels on a NiceMatrix. Otherwise, I've felt like I could do everything in Typst that I needed from LaTeX.

How difficult is creating templates from scratch? I generally use a document class like lecture[0] or report[1] in LaTeX but a quick search hasn't turned up anything similar for Typst.

[0]: https://ctan.org/pkg/lectures

[1]: https://github.com/SeniorMars/dotfiles/tree/main/latex_templ...

It's much easier than latex in my limited experience. For example I wanted to reproduce the 400-line .sty file I use for submitting assignments in the maths course I am studying in my part time. I have evolved that from something I found in someone's github over 3 years and it's still not quite right in some boring ways. This is 60 lines that I did in one afternoon and already it does everything the other one did and some things better than the old one.

> My only complaint is that all functions are pure functions; there is not a way (that I know of) to share state from one function invocation to the next.

Indeed user-defined functions are pure. You can work around it like the suiji package[1] does: have the function return a value that you pass as argument to the next call.

[1] Random number generator in Typst: https://typst.app/universe/package/suiji/

Yeah like wjholden said it's not hard. It takes a bit of adjustment but most of that ends up with simplification. For example, where on latex you use asmsmath and you need flalign, align and a bunch of other stuff on typst you just use the built-in equation setup, and customize it a bit if you want to (eg if your standard equation env in amsmath is flalign/flalign* then in typst you can just once set up those params (how you want it indented/aligned/padded/numbered) and after that $ block of equations $ is aligned and numbered the way you want with no further fuss. You can also do things like have a labeled equation block that only gets numbered if you end up using the label and the number goes away if you edit the reference away etc.

You want pandoc and markdown involved so that you can write once and transform your document into formats other than Typst.

https://lwn.net/Articles/1037577/

Personally, I'd much rather just write Typst than pandoc and it's horrible markdown variants. If Pandoc can do a good job of translating Typst documents to other formats, that's great, but I really dislike working with Pandoc's flavour of markdown.

The argument for Pandoc is that (last I checked) Typst doesn’t compile to e.g. HTML, EPUB, or DOCX. So if you’re writing something that should be available in multiple formats, it might still make sense to type it in e.g. Markdown and then Pandoc it to the other formats, but replacing TeX with Typst.

That said, I agree with you that I don’t see any reason to do Markdown -> Typst conversion unless you have multiple compile targets, as Typst syntax is pretty readable/writeable already.

For now I’m still using mostly TeX or Org-mode, but I made lecture notes for a class I taught last year in Typst and was pretty happy with that. Some things related to figures and tables felt a bit rough, and the Emacs mode for it also felt a bit WIP, but both are probably vastly improved by now.

Luckily, Typst actually has experimental HTML export which is progressing quite nicely (even with MathML in the next update!), see here: https://typst.app/docs/reference/html/

I wish the article showed what the markdown format for working with typst and pandoc looked like, and what an output PDF looked like. I have no idea whether I'm interested or not from this article

Examples pf typst styling here:

https://typst.app/docs/tutorial/advanced-styling/

And his template here:

https://imaginarytext.ca/posts/2025/img/article.typ

I've written typst, but if I understand correctly (which I'm really not sure I do?) the article is talking about markdown documents with pandoc commands in them that get translated into typst formatting, but I don't know what the _markdown_ looks like

At the risk of making a fool of myself in-front of the rest of the class, I will come out and admit I don't know what the article is talking about.

> Last summer I spent a lot of time with Typst (at that point v0.11) and Pandoc, working on a flexible and reusable workflow to typeset markdown-formatted articles to PDF.

I understand that Typst is a markup language that can output a pdf file (big Typst fan btw).

I understand Pandoc is a thing that transforms documents of one kind to documents of another, ie markdown to html.

But the author wants to "typeset markdown-formatted article to PDF". Which makes me wonder what this has to do with typst at all.

The author explain this in more detail in the article; I also was initially confused. The key details come from their broken down pandoc command. Specifically, these two flags:

  --pdf-engine=typst
  -V template=article.typ

Despite the input content being a .md file, we see that the .md contents populate the .typ file. Pandoc then understands how to convert the populated .typ file into a .pdf. The author also notes in their hyperlinked .typ document where the body content is placed:

  // THIS IS THE ACTUAL BODY:

What is not clear to me is the actual mechanism that tells pandoc where to place the body contents in the template. I presume it's some "magic" from the pandoc docs. The pandoc templates documentation[1] does reveal to us that `-V` is setting a variable called `template`. I don't have pandoc locally, but from another post[2] from the same author and a chatgpt query, it seems that the `body` symbol in the template is the chosen substitution symbol.

[1]: https://pandoc.org/demo/example33/6-templates.html

[2]: https://imaginarytext.ca/posts/2024/pandoc-typst-tutorial/

Pandoc templates use $...$ or ${...} for variable substitution, yes. body is one of the special default variables: the rest are documented in the manual. If you scroll to the bottom of the template linked from the article, you'll notice a $body$, along with a number of $if(...)$ $endif$ conditionals.

(This actually interferes with Typst's math mode. But you can manually construct math blocks, so no real problem. Pandoc variables are only valid within templates anyway.)

https://pandoc.org/MANUAL.html#variables-set-automatically

I'll give an example.

I write Python, software engineering, and data science books in Jupyter. (Because I want both text and code). I've written my own toolchain (multiple times, don't ask, yes, I've tried the one you're thinking of and it didn't work for me).

I need to convert the notebooks into chapters in my books (PDF so I can print them). In the past, I used code to convert to LaTeX. (It was horrible).

Now, I use code to convert the Jupyter file to markdown, then (I use pandoc too) to typst. (It is 100x better than LaTeX).

(I also use pandoc to convert markdown to epub).

> (multiple times, don't ask, yes, I've tried the one you're thinking of and it didn't work for me).

I know you didn't want questions, but maybe you can save me some trouble?

Assuming you're talking about quarto, may I ask what you didn't like about it? I've been converting some of my course materials to it and have been enjoying it immensely.

Quarto is one of them. When I checked it out, it wasn't usable for printed books (focused on papers). At that point (it's even easier now), I just painted my own bikeshed rather than dealing with others' weird angles and flooring.

For what's it's worth you can render Jupyter notebooks directly from Typst using the Callisto package. You can then style the notebook content as if it was written in Typst, using show rules, etc:

  #import "@preview/callisto:0.2.5"
  #callisto.render(nb: json("notebook.ipynb"))

though as the sibling comment says Quarto also works great for this, and Typst doesn't do epub (yet?)

Again, this is simplistic and not appropriate for a printed book...

I'm curious what would be a good example of something where this falls short of what you need?

I mean this Typst package just lets you import the notebook content in your Typst document. All the formatting is done in Typst which is also what you use for your final output...

Sidebars, front matter, index entries...

(Callisto author here)

Front matter would be fine I think. The static parts you would write directly in Typst. For the outline you would call #outline() as usual in the Typst document: notebook content is converted to Typst content (using cmarker), including the headings which become Typst headings so they show up as expected in the outline.

For sidebars I guess you use pandoc-Markdown extensions such as Divs that you transform with a Lua filter? What I would do then is use raw cells in the notebook to define sidebars (using Typst code in the raw cells) and configure Callisto to eval the raw cells.

For index entries, for example using the in-dexter package you could use HTML comments to insert index references where appropriate:

  <!--raw-typst #index[Entry]!-->

but I would just write #index[Entry] directly in the Markdown text, and use a show rule in the Typst document to convert them:

  #show regex("#index\[.*\]"): it => eval(it.text, mode: "markup", scope: in-dexter)

Overall, I think pandoc-Markdown + filters + Typst template is powerful and conceptually straightforward: you define the data structure with Markdown, you transform it with filters and render with Typst. Having the document as a well-defined data structure you can manipulate is especially powerful and something I wish we had in Typst.

In practice though it often feels overly complicated for little gains, when you can get things done with one tool and a single language (well, two since we're talking about including Jupyter notebooks).

Also working directly in Typst has advantages like live preview (also for content imported from notebooks), and some things that are a bit involved with pandoc, like maybe showing a cell output in a sidebar, become super easy: just add "#| label: my-cell" and "#| output: false" in the cell header, and #output("my-cell") in the side bar.

As the creator of a library that lets you import Markdown into Typst directly in the Typst build process, without the use of external tools like Pandoc, I confess I find it this all a little inconvenient!

It seems more advantageous to me to have only one build step and no intermediary files. We don’t support all the exotic features of Pandoc Markdown, but support much more customization in other areas.

The library: https://github.com/SabrinaJewson/cmarker.typ

I got a beautiful Latex template for my master thesis many years ago. I still remember fixing some things and it took me multiple days to figure out how this giant tangled web of a template worked. A year ago I tried to recreate the same look in a typst document. It took me less than a day to build it from scratch. Typst is genuinely one of the most awesome things I have seen in the last few years.

Thank you kind person for posting this. I've just started my Pandoc journey formatting books for reading in a secondhand Sony DPT-RP1.

From the article:

Last summer … Fast-forward to spring 2025. In the intervening months, Typst has been upgraded twice (to v0.13) and Pandoc has upgraded at least 3 times (currently at v3.6.4), and my templates don’t work anymore.

This template is from March 2025, and we're now May 2026, with four more releases to Typst 0.14.2 (December 12, 2025), and with Pandoc 3.9.0.2 (2026-03-19).

This template is a great starting point. I have tweaked [0] it for A4 and two-column output, if anybody is interested.

[0]: https://www.bobek.cz/til/pandoc-markdown-typst/

Very nice! I also like working from pandoc where possible - being able to split the output into a latex/typst file as well as a docx is very handy, especially when working with collaborators who are more comfortable with word. I wish markdown would see more support in scientific writing - it would solve so many of the headaches with formatting etc (and reduce microsoft's dominance in research)

Incidentally, I developed my own template for a markdown rendering pipeline: markdown -> pandoc -> typst, with mermaid diagrams.

This works very, very well. I get linked in-document references, diagrams, tables, table of contents — everything I need for my design documents (and consulting work).

I used the new one for a paper, and it was really easy and beautiful. Just the cross generated TeX for arxiv looked bad.

Reply on news.ycombinator.com