typst
Configure PDF export from the document
Description
As part of #2942 first PDF/A support landed. But the exported PDF standard can only be controlled through the CLI. I would like to configure my document as PDF/A from inside the document.
Maybe something like
#pdf_standard("A2-b")
or even a list like the CLI supports.
This could just be ignored by PNG/SVG export.
Use Case
Some documents will only make sense as PDF/A like electronic invoices with file embeddings.
I think it makes sense to either have it completely controlled from the CLI or completely controlled from within the document (which is what Latex does, I think), but having both would seem kind of weird to me.
This doesn't really seem viable considering Typst's current model, where World implementations are given a good degree of freedom to manipulate the laid out document in various ways. (Although I guess target information might be exposed in the future depending on the outcome of https://github.com/typst/typst/issues/4174, but that's still just informative and not enforced, and can be arbitrarily manipulated by the World implementation.)
At most, it could be an assertion such as assert(target().type == pdf and target().standard == "A-2b"), but that would depend on exposing target information as outlined above.
To elaborate on the use case: Electronic invoices might fail to export with PDF/A-2. They need to contain file embeddings that require PDF/A-3. In cases like this, the document knows it can only compile for certain specifications and could communicate that to the compiler/exporter. I see your point though about it being weird to configure through both, CLI options and the document.
Thank you for linking #4174. That could allow to skip the file embedding in cases where the document knows it would fail the export. But the result would not be an electronic invoice (still better than no PDF at all in some cases I guess).
After thinking about this more, I will close the issue.
Configuration through both, the Typst file and the CLI/editor/tool, is really strange. For the use case of e-invoices it seems enough to configure the right export through the tooling. Especially if we get something like #4174 to optionally prevent compilation failures for other exports.