include image output of LaTeX blocks in non-LaTeX formats

[wuqui]

I think it would be very powerful if one could include include the output of LaTeX blocks as images in html formats. I could imagine several use cases (e.g. complex tables), but the use case I’m interested most involves drawing trees in LaTeX using the forest package like this:

```{=tex}
\begin{forest}
  [1
    [2]
    [3]
  ]
\end{forest}
```

These work great for rendering to pdf, but when exporting to html (e.g. revealjs), I would like Quarto/pandoc to include a standalone image of these blocks.

Is this possible out-of-the-box already somehow? I have searched for quite a while, but maybe I missed it.

If not, any ideas how I could make it work – maybe using a Lua filter? I have no idea where to start for this.

[cderv]

Is this possible out-of-the-box already somehow?

This is not possible for now in Quarto. However, using external tools you can have this to work.

One example is using R in the qmd document. This will allow you to use this R package https://yonicd.github.io/texPreview/ that will do just what you are looking for. It should work as is within Quarto document as it works with knitr already.

maybe using a Lua filter? I have no idea where to start for this.

Using the syntax you described would indeed require to develop a Lua filter that would do quite the same as the R package I mentioned. This could be a good Quarto extensions. I don't think there is one yet.

We have some information on creating extensions and working with Lua in our doc: https://quarto.org/docs/extensions/lua.html

Hope it helps

[wuqui]

Thanks a lot for your quick and helpful reply.

I have now checked both options and both work. After getting texPreview to work, I had a sense that a Quarto extension would be the more elegant solution, though, so I tried to get that running and eventually did. I tried to make it more broadly applicable by reading LaTeX requirements from a preamble.sty file, so that it’s not bound to my particular use case of the forest library and so that requirements are shared between Quarto’s ‘normal’ pdf processing and the extra runs for creating svg images.

I’m new to pandoc/Quarto and Lua, so suggestions are most welcome: https://github.com/wuqui/teximg. If it’s interesting to others, it could also be added to the Quarto extension list – I don’t know whether it’s useful/fancy enough for that, though …

One thing I haven’t figured out yet is how to specify the size of the image?

[cderv]

Awesome well done !

If it’s interesting to others, it could also be added to the Quarto extension list – I don’t know whether it’s useful/fancy enough for that, though …

I think that depends on how much you plan to use it and maintain this. This is something I wanted to do too, but did not had time for it. That is cool you did it. I would be happy to take over also at some point if you don't plan to maintain it yourself.

Regarding listing, you should add some tags to your github repo if you want discoverability (like quarto, quarto-extension, ...). And if you want it to be listed on the website, you can do a PR

Thanks a lot for this !

[wuqui]

Thank you very much, I’m happy to hear that 🙂

I would be happy to have it listed. My use case involving the forest package is probably quite rare, but I think the general functionality of including standalone images of LaTeX blocks in non-LaTeX outputs could be more widely useful, so I would be happy if it is useful for others.

Thanks for the tip about the PR, I didn’t know that. I think I’ll do that then. Before I do, I would just like to see if I can optimize two things:

1. How could I specify the display (font) size of the svg file (for example, in html output)? It’s quite small.
2. Is it possible to use the LaTeX requirements specified in the Quarto yaml? That would seem more Quartonic than relying on a preamble.sty 😉

[cderv]

I think the general functionality of including standalone images of LaTeX blocks in non-LaTeX outputs could be more widely useful, so I would be happy if it is useful for others.

Definitely useful from my experience !

Is it possible to use the LaTeX requirements specified in the Quarto yaml? That would seem more Quartonic than relying on a preamble.sty

If some dependencies are required by your extensions, best things is to add the latex dependency you need using this Quarto API from Lua https://quarto.org/docs/extensions/lua-api.html#dependencies. See example in our extensions like how we allow using fontawesome incons in LaTeX document

Otherwise, this is dependency need by the user to run each raw TeX block right ?

The idea of preamble.sty is nice. Otherwise, you can add some config in YAML for your extension. See example with our latex-environment extension - it can read some information from YAML config.

If you want something more scoped to the raw tex block, you'll need to leverage other structure because you can't set ID or attributes on those structure. So it would need to be like enclosing the raw block in a div with attributes or leveraging another syntax than the raw block, but more complex filter at the end.

[jdutant]

I'm writing a Quarto/Pandoc filter that does this, with pretty extensive customization options, e.g. zoom that you can specify for the whole document, classes or individual elements. It can also embed svg images within the html output file. It's functional, though I've focused on HTML output and MacOS/Linux only so far. I'll do further tests and add a better sample document before I create a release. But you can already have a look (issues and suggestions welcome!)

https://github.com/dialoa/imagify

Note: to see a sample output you'll have to clone and run make generate && open test/expected.html. The sample output in the online documentation doesn't yet work but thta's just because it's generated on GitHub using the pandoc/latex docker image, which unfortunately doesn't include the standalone LaTeX document class.

[cderv]

👍 Indeed, the filter could by default push 'up' to the root whatever header-includes is provided under the global imagify key (or the global and classes?).

What I meant really is not just pushing to the root, it is handling metadata under imagify key to do the right thing. Quarto has a specific Lua API to help, among other thing, add some dependencies to LaTeX or HTML. This means it does not rely on Pandoc handling of header-includes. Put the link again at the doc: https://quarto.org/docs/extensions/lua-api.html#includes

I believe this would give you some more flexibility as you can catch the meta, do something and remove it for Pandoc to ignore it later on.

I think that won't work right? Because we're rendering the whole document to HTML, while we're turning its LaTeX elements to LaTeX/PDF. in-header can't be used, because it'll place "usepackage..." in the HTML document header. (The filter could look for those there and remove them, but that's a hassle.)

And the above is definitely for that without much hassle thanks to the Quarto Lua API.

include-in-header doesn't work either, because Quarto (surprisingly!) includes the .tex as RawInline with html format

It don't find that surprising. include-in-header is not really meant to be global as usually file included will differ in HTML and PDF. So for multi format document, one would add include-in-header under each format key.

format:
  html:
    include-in-header: head.html
  pdf:
    include-in-header: head.tex

include-in-header assumes that the file passed to it is compatible with the format used.

Yes, the filter is looking for all the official LaTeX-relevant Pandoc keys that are applicable to a standalone document.

Quarto has some custom fields so this may need to be adapted or at least be made compatible. Not so much difference I think.

The filter looks for them both at the root and under imagify (the latter overriding the former). Seems fine?

Yes - It seems fine to me to use same name key as default Pandoc. What I am suggesting is doing some special treatment in Lua and not just passing them through to override. This way I think you could catch a raw content in LaTeX that would be remove in HTML output and use it for your HTML processing.

Anyhow, maybe I am missing something. If you are interesting, I can try do an example of what I mean in your repo. We can also discuss this topic in an issue in your repo.

Thanks a lot for the discussion !

[jdutant]

Thanks @cderv this is helpful. I now get the point about the Lua API. I'll start posting issues I can think of for making use of all the quarto goodies, and to make sure the filter works well with the ecosystem. Any suggestions / PRs welcome, and I'll come here for help.

[jdutant]

One quick question though: in Quarto, can a filter retrieve what options (e.g. pdf-engine, etc) the user sets for LaTeX/PDF output when we're rendering a document to HTML? If I recall well from my tests meta values set at the root like mainfont are passed no matter what the output format is, but those set under format: pdf: are ditched. Can we still access them with the Lua api, e.g. quarto.doc.pdf_engine()?

[cderv]

Can we still access them with the Lua api, e.g. quarto.doc.pdf_engine()?

That is a good question. you should try to see what it renders in Lua. It could be a matter of where we're at in the Lua evaluation order, but it is highly possible that for HTML all keys under pdf format at not read for HTML output. 🤔

Please do ask your questions like that in new topics maybe so that we can discuss more clearly with the rest of the team specific use case like that.

[jdutant]

Thanks, I'll test it first.