Preliminary Support for Typst in knitr

Yihui Xie 2026-04-27

A few weeks ago I added preliminary support for Typst to knitr. The way it works is simple: if your file has the extension .Rtyp, knitr will recognize it as a Typst document, knit it, and produce a .typ output file. The chunk syntax follows the same Markdown-style fenced code block convention: ```{r} to start a chunk and ``` to end it, with inline R expressions written as `r expr`. A minimal example (hello.Rtyp):

#set page(paper: "a4")
#set text(font: "New Computer Modern", size: 11pt)

= Hello, Typst!

```{r}
x = rnorm(10)
summary(x)
```

The mean is `r round(mean(x), 3)`.

Install the latest development version of knitr and restart R:

install.packages('knitr', repos = 'https://yihui.r-universe.dev')

Then you run either:

knitr::knit("hello.Rtyp")      # produces hello.typ
knitr::knit2pdf("hello.Rtyp")  # produces hello.pdf

That’s about it. I called this “preliminary” support because I have not done extensive testing, and there are probably rough edges. If give this a try and run into any problems, please feel free to leave comments below or file issues to the knitr repo on Github.

On Typst itself

Typst is quite impressive and its rendering speed seems to be unbeatable. I understand why so many people in the R community are excited about it. However, for knitr / rmarkdown / Quarto users, I think the bottleneck in dynamic documents (.Rtyp, .Rmd, .qmd) is almost never the typesetting step—it’s the computation in code chunks. The speed argument for Typst is compelling for pure writing workflows; for data analysis documents, I’m skeptical it matters much in practice.

And then there is the larger question of whether you need PDF at all.

In HTML I Still Trust

I have believed for a long time that HTML is the better target for almost everything, including what people typically reach for PDF to accomplish: typesetting for reading, sharing, and archiving. You get hyperlinks, search, accessibility, reflowable text, responsive layout, and zero installation requirements—free, in a browser that everyone already has.

If you really need paginated output that looks like a printed document, it is more achievable from HTML than you’d imagine. I have a small script pages.js that typesets a continuous HTML page into individual pages—you can press P (or Ctrl/Cmd + P) on any page at yihui.org/litedown/ to see the effect. The result is not perfect, but it is good enough for many use cases, and you get to keep all the benefits of HTML along the way. BTW, I handcrafted pages.js from scratch in 2024 without AI assistance, and I have to confess that while the code is relatively short, it was the most challenging piece of JavaScript I had ever written (again, the recursion almost killed me). I guess today’s AI can do a much better job than me.

The accessibility angle is one I keep hearing more about, and rightly so. HTML is dramatically better than PDF on this front—screen readers, keyboard navigation, zoom, high-contrast mode, all of it works because browsers have been doing this for decades. LaTeX has finally made some progress here, too (e.g., the tagpdf package), which is great, but still there are so many things that I doubt would ever become possible in LaTeX.

Bye, LaTeX (and Typst, although we never met)

Typst support in knitr is there if you want it, and I think Typst is a great tool. I wouldn’t use it myself but I’m happy to serve those who do use it. I gave up MS Office around 2009 after becoming a LaTeX fan for a few years. In 2024, I decided that I wouldn’t use LaTeX anymore (when I need PDF, I just use pages.js to print HTML). I believe HTML still has a lot of potential that I need to explore further, and I really look forward to it.

Again, this doesn’t mean I’m abandoning my support for LaTeX. Actually I still work quite hard in this regard, as you can tell from some of my previous posts this year.