Is there a way to detect the output format in a JSON filter?

[matthew-brett]

I have a series of JSON filters in my book that pull out information from the documents, in fact to generate an .ipynb notebook from the pages.

However, I don't want to execute these twice when outputing HTML and PDF documents with quarto render ..

Is there a way for my JSON filter to know which output format it is currently rendering, so I can ensure the particular filter only runs for e.g. the HTML rendering? I see a Lua filter can ask e.g. quarto.doc.is_format("latex"), but is there an equivalent within a JSON filter?

[cscheid]

No, and that's one of the fundamental problems of a JSON filter - lack of access to the pandoc and quarto APIs. You could perhaps write two filters, one Lua filter that injects information into the metadata using the API, and then the JSON filter has access to it.

[matthew-brett]

I guess this is a common case. Would y'all consider putting this into the JSON by default? Or providing a filter to do that?

[cscheid]

I guess this is a common case. Would y'all consider putting this into the JSON by default? Or providing a filter to do that?

There's no way to do that: the Lua API can be called with infinitely many possible values. The decision of "Which should we provide?" is precisely equivalent to you writing two filters.

[matthew-brett]

Er - yes - I wasn't asking for every possible value from the API, just the format (latex, html etc) - given that it will - I imagine - be a common need.

[cscheid]

We'll take your request into consideration, but I truly am reluctant to do this. Even "just" the format is currently a non-exhaustive set of 25 calls.

For example, we don't have a ready way to check if you're running against a custom format (say, one from extensions which define journal-specific formats). For that, you will need to get information from the Lua API (since we can't know ahead of time what user extensions could possibly exist).

In contrast, the additional filter you'd have to write is typically 10 lines of code. We do try hard to keep JSON filters a possibility, but we fundamentally can't support everything in the Lua API, because these limitations come from Pandoc itself. Pandoc Lua filters were designed specifically so you can write code against the Pandoc API; patching it all in JSON is not practical.

[matthew-brett]

If choosing between "All" or "Nothing" I can see you'd go for "Nothing" - All is not practical. What I was thinking of was the best-effort basics - so in this case, I guess having an injected format of one of html|pdf|docx|custom or something like that.

[matthew-brett]

My current solution is the following little filter add-meta.lua:

--[[
This filter adds metadata to the document.

This allows us to add useful information visible to Pandoc and
Quarto, but not available in a Python / Panflute filter.

See: https://quarto.org/docs/extensions/lua-api.html
]]

return {{
    Meta = function (meta)
        for _, fmt in ipairs({'html', 'latex',
                              'docx', 'markdown'}) do
            if quarto.doc.is_format(fmt) then
                out_format = fmt
                break
            end
        end
        meta['quarto-doc-params'] = {
            output_directory = quarto.project.output_directory,
            input_file = quarto.doc.input_file,
            output_file = quarto.doc.output_file,
            out_format = out_format
        }
        return meta
    end
}}

I'm sure it could be improved, but it has the desired effect, of filling in a new key in the JSON metadata like this:

  "quarto-doc-params": {
    "input_file": "/Users/mb312/dev_trees/resamp-test/source/index.Rmd",
    "out_format": "html",
    "output_directory": "/Users/mb312/dev_trees/resamp-test/source/../r-book",
    "output_file": "/Users/mb312/dev_trees/resamp-test/source/../r-book/index.html"
  },