Prefer text/latex and application/pdf mime types when rendering latex

[jkrumbiegel]

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]

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

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

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

[cscheid]

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]

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?

[jkrumbiegel]

@cscheid could you help me with the testing issues I noted above? Would be great to get this sorted :)

[cderv]

@jkrumbiegel I am just adding some tests related to rsvg-convert presence in #13661

So possibly this will help here.

But I'm not sure how to test the actual issue, the problem will only appear when rsvg-convert is not available

To clarify, we don't have rsvg-convert on the PATH in our CI. So, if you want to test without it, you can already do so. If you want a test with rsvg-convert on PATH, then we'll add it among the tests that require it, and it will be installed. This will work for now with smoke/ test as *.ts file.

How does one test that a specific output has been used for the final result?

Using *.ts file for test give you more flexibility that using smoke-all document. If you describe me what you want to test, I can do the test. Otherwise, you can look at some of our .test.ts file in smoke/.

[jkrumbiegel]

@cderv The issue was that from the images available in the ipynb, SVG was preferred over PDF when rendering LaTeX. But this would only be noticeable if the required conversion via rsvg-convert failed. So without involvement of rsvg-convert at all, the test would somehow have to show that PDF was picked for the final render, what pandoc receives. But I'm not sure how that could be done.

[jkrumbiegel]

@cderv friendly bump :)

[jkrumbiegel]

Ok, I've had another go at this with Claude, removed the (nonessential) parts that belong in the julia extension now, and added a test file that I confirmed locally to fail without the code changes. Maybe this can still make it into 1.9 then, given it's such a small change.

[jkrumbiegel]

one more bump :)

[cderv]

Thanks. i'll take a look