-
-
Notifications
You must be signed in to change notification settings - Fork 805
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Export target elements #4174
Comments
|
I think the question of a I want to have a As for the target-specific metadata: I see how adding it all to I would prefer to get some experience with target-specific things with |
Yeah, to be completely honest, it probably only serves as an example of things that one may want to control for other output formats. Since I haven't really touched SVG at all, yet I wouldn't know if there is anything for that and for PNG this is the only thing that seemed similar to PDF specific metadata. It will probably be more relevant for HTML.
Somewhat understandable, but it does impose something on PDF forms, namely that they must always be exported at this moment if there is no way to turn them off conditionally. But maybe their implementation will help in exploring the right API. |
I don't follow. Wouldn't a |
Oh, pardon me, I misunderstood. |
Description
I propose adding
document
-likeset
-rule only elements for export targets to control target specific settings:png
pdf
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:svg
)pdf.a2
orpdf.x
target == pdf
would be false fortarget == pdf.a2
, users would need to usetarget in (pdf, pdf.a2, pdf.x)
, listing all possible sub-targetsUsing strings solves this more easily, as these sub-target checks could use string methods like
target.starts-with("pdf")
or eventarget.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
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:
Export targets such as HTML HTML Export #721 likely need more export target specific code, as it is fundamentally different from how Typst currently works.
The text was updated successfully, but these errors were encountered: