Why do I get an error when rendering with Typst on macOS?

[cbrnr]

I'm sorry, me again ☺️. I was trying to render a PDF with Typst, but if I include an executable R code cell, I get an error (see below). Here's the minimal example:

---
title: "Untitled"
format: typst
---

This is some introductory text.

```{r}
x = 1
```

Interestingly, Python code works (just replace {r} with {python}).

This is the error:

processing file: Untitled-1.qmd
1/3                  
2/3 [unnamed-chunk-1]
Error in `dev.control()`:
! dev.control() called without an open graphics device
Backtrace:
  1. global .main()
  2. execute(...)
  3. rmarkdown::render(...)
  4. knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
  5. knitr:::process_file(text, output)
     ...
  9. knitr:::call_block(x)
 10. knitr:::block_exec(params)
 11. knitr:::eng_r(options)
 12. knitr:::chunk_device(options, keep != "none", tmp.fig)
 13. grDevices::dev.control(displaylist = if (record) "enable" else "inhibit")
Warning messages:
1: In grSoftVersion() :
  unable to load shared object '/Library/Frameworks/R.framework/Resources/modules//R_X11.so':
  dlopen(/Library/Frameworks/R.framework/Resources/modules//R_X11.so, 0x0006): Library not loaded: /opt/X11/lib/libSM.6.dylib
  Referenced from: <34C5A480-1AC4-30DF-83C9-30A913FC042E> /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/modules/R_X11.so
  Reason: tried: '/opt/X11/lib/libSM.6.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/X11/lib/libSM.6.dylib' (no such file), '/opt/X11/lib/libSM.6.dylib' (no such file), '/Library/Frameworks/R.framework/Resources/lib/libSM.6.dylib' (no such file), '/Library/Java/JavaVirtualMachines/jdk-11.0.18+10/Contents/Home/lib/server/libSM.6.dylib' (no such file)
2: In cairoVersion() :
  unable to load shared object '/Library/Frameworks/R.framework/Resources/library/grDevices/libs//cairo.so':
  dlopen(/Library/Frameworks/R.framework/Resources/library/grDevices/libs//cairo.so, 0x0006): Library not loaded: /opt/X11/lib/libXrender.1.dylib
  Referenced from: <CD76626B-D45F-32D3-92D5-A00446919021> /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library/grDevices/libs/cairo.so
  Reason: tried: '/opt/X11/lib/libXrender.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/X11/lib/libXrender.1.dylib' (no such file), '/opt/X11/lib/libXrender.1.dylib' (no such file), '/Library/Frameworks/R.framework/Resources/lib/libXrender.1.dylib' (no such file), '/Library/Java/JavaVirtualMachines/jdk-11.0.18+10/Contents/Home/lib/server/libXrender.1.dylib' (no such file)
3: In (function (filename = if (onefile) "Rplots.svg" else "Rplot%03d.svg",  :
  failed to load cairo DLL

[mcanouil]

Likely an issue with your R installation.
Look at the final errors that R (not Quarto) is emitting about shared libraries.

[mcanouil]

I don't know, it seems to be a knitr behaviour regarding markdown/HTML output (knitr does not emit Typst).

I am pretty sure you'll have the same issue using RMarkdown instead of Quarto. By the way could you try? (not with Typst obviously)
Do you see the same issue using format: pdf for LaTeX?

[cbrnr]

Setting format: pdf works fine, so I'm not sure how to test this with RMarkdown. I agree that it might have to do with knitr, but maybe it's because Quarto uses knitr incorrectly?

[mcanouil]

Since LaTeX works (no need to try Rmarkdown), it could be Quarto internal R code.
@cderv is the one that knows both knitr and Quarto R codebase. He might have some ideas of why in the context of Typst, a graphical device is required for something that does not seem to actually need one.

[cderv]

Setting format: pdf works fine, so I'm not sure how to test this with RMarkdown. I agree that it might have to do with knitr, but maybe it's because Quarto uses knitr incorrectly?

This is a matter of graphic device.

• format: pdf sets for knitr dev = 'pdf' which means grDevices::pdf() will be used.
• format: typst sets for knitr dev = 'svg' which means grDevices::svg will be used.

Now in R, from ?grDevices::svg, see the note

In principle these devices are independent of X11 (as is seen by their presence on Windows). But on a Unix-alike the cairo libraries may be distributed as part of the X11 system and hence that (for example, on macOS, XQuartz) may need to be installed.

This is why you get a difference in behavior.

But I shouldn't be required to have XQuartz installed just to render the document, or no?

As you see this is a R requirement on MacOS, when default devices are used. You will get the same error with rmarkdown if you use a dev that requires X11 on MacOS.

You need to have XQuartz installed so that R graphic device works on MacOS. XQuartz is a requirement of R on mac it seems. From https://cran.r-project.org/bin/macosx/

Note: the use of X11 (including tcltk) requires XQuartz (version 2.8.5 or later). Always re-install XQuartz when upgrading your macOS to a new major version.

It seems this is a requirement since R 3.3.3 as OSx does not include it. From same page:

Note: the use of X11 (including tcltk) requires XQuartz to be installed since it is no longer part of OS X. Always re-install XQuartz when upgrading your OS X to a new major version.

If you don't want to install XQuartz, you need to change the default. Either don't use svg and use another device compatible with Typst. Of you could use svglite R package by passing the option to knitr.
Either in YAML header

knitr:
  opts_chunk:
    dev: svglite

of setting the option in a cell using knitr::opts_chunk$set()

a graphical device is required for something that does not seem to actually need one.

In knitr and evaluate the graphic configured is started before executing any cells, so that any graphics are recorded in the right place. The code cell is not statically analyze to know the source code is about calling a plot. And the graphic device needs to be open before running a code that results in plot. So knitr does open it at the start of execution.

Hope it helps understand.

[cbrnr]

Thanks for this great explanation @cderv!

From a user perspective, I don't think that this behavior makes sense though. Since X11 is not distributed with R, my guess is that most R users on a Mac won't have it installed. Also, I really don't want to install this ancient piece of software just to render to Typst.

However, as you suggested, using the svglite device works great! I think it would be really helpful if Quarto used that as its default. Do you think this would be a good idea? Personally, I'd rather install this small R package than an X11 server...

[cderv]

However, as you suggested, using the svglite device works great! I think it would be really helpful if Quarto used that as its default.

I don't think we want to make a R package a requirement to use Quarto. svglite is not installed by default with rmarkdown

> pak::pkg_deps_explain("rmarkdown", "svglite")
x svglite 

And not even as a Suggest one it seems

> pak::pkg_deps_explain("rmarkdown", "svglite", dependencies = TRUE)
x svglite  

So what could be done is something like dev = if (xfun::pkg_available("svglite")) "svglite" else "svg"
But this would imply the default device would be different depending on the current environment... 🤔
Though there would be no way to opt-out, unless we do this if dev is not set initially.

knitr:
  opts_chunk:
    dev: svg

would be the way to revert for a project or document.

I don't think what is best here, though I agree this can be a problem is more and more environment are not having X11. But ultimately this is R graphic device requirement for svg.

Otherwise, knitr could use svglite by default, and add it as a dependency, but I think last time I discussed this, we feared breaking change so change the default.

Currently doing

knitr:
  opts_chunk:
    dev: svglite

if the way to go.

I think there is also a way to set the device in knitr globally in R profile through option or environment variable so that svglite is used as a default svg device.

[cbrnr]

Maybe worth asking the knitr devs again? To be clear, I don't have a problem setting the svglite device in the header (or globally or whatever), but I really think that requiring X11 on a Mac in 2025 to render to Typst is not great (and I'm assuming that Typst will get much more popular over time).

[cderv]

@cbrnr A fallback mechanism is supposed to be on knitr to prevent problem with device not working.

Can you try for me

(knitr:::dev_available("svg"))

I wonder if we have not an issue in knitr to fix in fact 🤔 . I think this would reproduce the error you have

knitr::opts_chunk$set(dev = "svg")
knitr::knit(text = c("```{r}", "x = 1", "```"))

Can you try it too ?

[cderv]

Better user experience to be discussed in

• [knitr] Consider defaulting to svglite when svg device is used on R (e.g. as default in format: typst) #11712