Export target elements

[tingerrr]

Description

I propose adding document-like set-rule only elements for export targets to control target specific settings:

• png
  • controlling PPI from within Typst documents
  • although this may open a small DOS attack surface from template packages choosing astronomical values
• pdf
  • PDF document metadata, which is currently set using document

Use document either for only the common settings or as a convenient default for various settings from multiple targets.

Alongside this, a variable such as target should be added, which is set depending on the current export target. This allows code to act according to the export target, preventing incorrect output or panics when a target specific feature is used, such as Forms #2421 or OCGs #2613.

The newly added elements and variable could be put into an export module, i.e. set export.pdf(...), if export.target == export.pdf { ... }, as they should not require easy access for the majority of users.

While I thought about the target variable being the element of the active export target for nice looking checks (target == pdf), this comes with some downsides:

• elements with no fields must be available too (svg)
• sub-targets, such as #2942 are not easily accounted for unless they receive potentially useless sub-elements like pdf.a2 or pdf.x
• if sub-elements are added, they would complicate the simple checks as the equality would no longer hold target == pdf would be false for target == pdf.a2, users would need to use target in (pdf, pdf.a2, pdf.x), listing all possible sub-targets

Using strings solves this more easily, as these sub-target checks could use string methods like target.starts-with("pdf") or even target.starts-with("pdf/a") for all versions of PDF/A.

Most of the sub-target specific settings will likely live on the "encompassing" element anyway (i.e. pdf for PDF/A).

Use Case

1. Export target specific features which are likely to be more "low-level" than normal Typst features if they can't be easily generalized will likely need packages to be made usable for the average Typst user.

   Such packages need to be able to:

   • use export target specific features without panics (if they do when used on an unsupported target)
   • provide reasonable fallback behavior, when the target specific feature is not supported
     • this is especially important for preview of features which are not available for PNGs, such as forms
     • provide example images of target specific features without the need to take screenshots of PDF viewers to show of export target specific packages

2. Export targets such as HTML #721 likely need more export target specific code, as it is fundamentally different from how Typst currently works.

[emilyyyylime]

target sounds like it'd fit inside the sys module, but I'm not too against export either