Skip to content
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

Add targets #1904

Closed
wants to merge 4 commits into from
Closed

Add targets #1904

wants to merge 4 commits into from

Conversation

SekoiaTree
Copy link
Contributor

This PR adds support for targets, which allow a document to know what it's being compiled into.

This is part of the basics that will eventually allow HTML compilation.

Currently missing:

  • tests (might not be needed? They don't really work with the existing testing pipeline, since they're meta)
  • clippy. So much clippy (probably)

@reknih
Copy link
Member

reknih commented Aug 10, 2023

In my opinion, it should not be PNG but raster or similar. We create a pixel buffer, the file format / compression is incidental. For example, we could also produce a TIFF or JPEG but the target considerations should be the same.

@SekoiaTree
Copy link
Contributor Author

Should I change SVG to vector or similar, then?

@SekoiaTree
Copy link
Contributor Author

I ended up changing Png to Raster and Svg to Vector. Pdf stays the same since it's really the only format that renders... like that.

@LaurenzV
Copy link
Sponsor Collaborator

LaurenzV commented Aug 11, 2023

To be honest, I'm personally somewhat against having such a feature in Typst, at least at the current stage. Because by introducing the possibility to add target-specific code, we can no longer expect all of the output formats to look the same, which in my opinion is an unfortunate side-effect, especially for the web app, since then the outputted PDF might look differently than what was shown in the preview.

I'm aware that since HTML support is planned, at some point there might have to be a way to introduce target-specific code (although I have no clue how this could be done in a nice way), but at least for now, while we still have the same frame-based representation for each output format (PNG, PDF, SVG), I would personally steer away from allowing users to specify target-specific code, at least until more details about how the distinction between layouted and pageless formats will be dealt with have been hashed out.

Just my two cents though. 🙂

@PgBiel
Copy link
Contributor

PgBiel commented Aug 11, 2023

We could perhaps delay this change to when HTML export is added, and maybe have a way to differentiate HTML export from the rest. Regarding differentiating PDF / PNG / SVG, that could be postponed until we have a proper discussion on whether that's worth it or not.

@laurmaedje
Copy link
Member

I originally thought that there was no harm in supporting this as is already, but it is true that there's still a discussion to be had how fine-grained targets should be. It could be per-format with simple accessors for groups of related formats or it could be that we only expose the group information. We could even store the format internally, but not expose it and that way still have overlapping groups of formats (like is-layouted, is-x, is-y).

@laurmaedje laurmaedje added the waiting-on-design This PR or issue is blocked by design work. label Sep 4, 2023
@laurmaedje laurmaedje marked this pull request as draft September 11, 2023 08:50
@laurmaedje
Copy link
Member

I'll close this for now as things will still take a bit. We can see again then. I might also just add this alongside other stuff when I'm working on the relevant parts.

@laurmaedje laurmaedje closed this Nov 17, 2023
@laurmaedje laurmaedje mentioned this pull request Jun 12, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting-on-design This PR or issue is blocked by design work.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants