Document `quarto.doc.add_typst_font_path()`

[cderv]

This was added in

• Feature/typst brand yaml #10647

but not yet documented in https://quarto.org/docs/extensions/lua-api.html

However, it is not used yet anywhere in the codebase - so unsure if this is leftover or feature.

cc @gordonwoodhull

[gordonwoodhull]

The story here is that we had this functionality briefly but we weren't using it because the Typst font resource handling moved from Lua to Typescript.

So we removed it in 7bac8f0, but we missed the Lua API when doing so. This is dead code which should be removed.

It did work, but it seemed like a lot of work for an obscure feature. As I commented when implementing it, it would be better to have something that outputs metadata to be merged into the format metadata.

[cderv]

Ok I understand this is now on typescript side. As the idea is to contribute some fonts from an extension to quarto format typst rendering, if we don't do it in LUA, would that mean we could add a specific contribute mechanism for typst fonts using extension metadata ?

Using LUA felt the right way to contribute from extension filter or shortcode, like we do for other dependency... 🤔

As I commented when implementing it, it would be better to have something that outputs metadata to be merged into the format metadata

What do you have in mind by "something that outputs metadata" ? Does this means having the Lua filter output some metadata that would be merged with Quarto ones before typst rendering ?

I wonder when it is too late in the process to contribute fonts

[gordonwoodhull]

It’s absolutely correct and proper to contribute fonts from a filter or extension! And there isn’t any timing issue.

The tricky thing here is our old friend the “which metadata?” problem. We can’t use the built-in mechanism to modify the Pandoc metadata in Lua, because that metadata only goes to the templates.

What we need to do in this case is contribute values to format.metadata.

If you look at the removed code in the commit I linked above, you’ll see that I implemented something which does almost all the work that would be required to contribute format metadata in general for any format and any metadata, short of actually calling mergeConfigs

But it’s limited to Typst and font paths, and that seemed like a shame to me.

Not having any other need to contribute format metadata besides Typst font paths, it didn’t seem worth generalizing. But it also seemed too complex to keep when we were no longer using it. So I removed the code.

But it could be restored, and possibly generalized.