Update pdf-engine.qmd #752
Conversation
doc fix for quarto-dev/quarto-cli#5677
| @@ -11,6 +11,15 @@ While you can employ whatever toolchain you like for LaTeX compilation, we stron | |||
|
|
|||
| We also recommend the use of Quarto's built in PDF compilation engine, which among other things performs automatic installation of any missing TeX packages. | |||
|
|
|||
| Please note that TinyTex is a distribution not a PDF engine. To see all engines supported by Quarto, try this command (example output also shown). | |||
There was a problem hiding this comment.
Thanks for this! We actually default to the xelatex engine (for unicode support and font compatibility) so we should probably indicate that (or just change the example to `pdf-engine: xelatex'. We might also want to link to an article that explains the pros and cons of the different engines.
Finally, it's not really useful to show all of those pdf engines as many of them are only used w/ HTML (wkhtmltopdf, weasyprint, pagedjs-cli, prince). Others like latexmk and tectonic are duplicative with our built-in compilation loop / auto-package installation (and less likely to work well since don't maintain or fix bugs in those projects). context is a totally different world that users shouldn't casually enter! (as all of our LaTeX features don't work in context).
So for the purposes of this article I think we should focus on the 3 mainstream options for PDF output, letting people know the default as well as how to learn more about customizing it.
Note that if you actually try to the HTML to PDF engines they don't work well at all out of the box w/ our default HTML output. In practice, you need to hand craft HTML and CSS for these engines so they are way more than just an "option", but rather each of them it's own dialect not really supported by Quarto per-se (that's why we don't document them or encourage their use).
doc fix for quarto-dev/quarto-cli#5677