Skip to content

Conversation

@jkrumbiegel
Copy link
Contributor

Currently, rendering a qmd which creates a CairoMakie plot to pdf via LaTeX can error if rsvg-convert is not available on the path.

FATAL (/Users/user/dev/quarto-cli/src/resources/filters/./quarto-post/pdf-images.lua:22) An error occurred:
Could not convert a SVG to a PDF for output. Please ensure that rsvg-convert is available on the path.
Error running filter /Users/user/dev/quarto-cli/src/resources/filters/main.lua:
...o-cli/src/resources/filters/./quarto-post/pdf-images.lua:46: FATAL QUARTO ERROR
stack traceback:
        ...el/dev/quarto-cli/src/resources/filters/./common/log.lua:34: in function 'fatal'
        .../dev/quarto-cli/src/resources/filters/./common/error.lua:14: in function 'fail'
        ...o-cli/src/resources/filters/./quarto-post/pdf-images.lua:22: in upvalue 'call_rsvg_convert'
        ...o-cli/src/resources/filters/./quarto-post/pdf-images.lua:46: in function <...o-cli/src/resources/filters/./quarto-post/pdf-images.lua:28>

An example qmd for this is

---
engine: julia
---

```{julia}
using CairoMakie

Figure(backgroundcolor = :tomato)
```

Now I was wondering how this could happen if CairoMakie is able to produce both svg and pdf outputs. I would have expected this error to only appear when only svg was available. However, I confirmed that with default settings, the julia engine sends back svg, pdf and png within the jupyter notebook JSON.

I then checked why the pdf output was apparently ignored and I noticed that the text/latex and application/pdf MIME types were added to the end of the priority queue for latex, which meant that any other MIME type would take priority. I've fixed this by changing push to unshift following the earlier entry for markdown.

I'll need some help in adding a simple test for this, having rsvg-convert on the PATH will hide the problem.

Checklist

I have (if applicable):

  • filed a contributor agreement.
  • referenced the GitHub issue this PR closes
  • updated the appropriate changelog in the PR
  • ensured the present test suite passes
  • added new tests
  • created a separate documentation PR in Quarto's website repo and linked it to this PR

@posit-snyk-bot
Copy link
Collaborator

posit-snyk-bot commented Oct 20, 2025

Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
Licenses 0 0 0 0 0 issues
Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@cscheid
Copy link
Collaborator

cscheid commented Oct 20, 2025

I'll need some help in adding a simple test for this, having rsvg-convert on the PATH will hide the problem.

I can help you with that.

Quarto structures its before- and after-engine files so that you can take the .ipynb (or keep-md) output of an engine and call quarto render on that file directly. So an engine-less reproduction of what you're seeing could be just a matter of adding keep-md: true or keep-ipynb: true to your .qmd file. This is how we often debug knitr and jupyter engine issues.

With that said, I wonder if engine: julia is handling the ipynb-to-qmd conversion differently, where the .ipynb file is not actually recorded.

At the same time, I think you should be able to figure out how to make engine: julia produce that .ipynb file, from which quarto render should just work. That would be a good start for a reproduction and regression test here.

@jkrumbiegel
Copy link
Contributor Author

Ok I've added the ability to set keep-ipynb: true to the julia engine and rendered an ipynb with the svg/pdf outputs and stored it in a smoke test folder. But I'm not sure how to test the actual issue, the problem will only appear when rsvg-convert is not available because otherwise the svg would have been picked and converted without problems. How does one test that a specific output has been used for the final result?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants