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

Minimum PDF/A support #81

Merged
merged 4 commits into from
Sep 30, 2024
Merged

Minimum PDF/A support #81

merged 4 commits into from
Sep 30, 2024

Conversation

laurmaedje
Copy link
Member

@laurmaedje laurmaedje commented Sep 27, 2024

This is the absolute minimum of additions for PDF/A support (PDF/A-2b).

The API is not that great since there are various standard one can conform to and here it's just a bool, but maybe that is out of scope for the current svg2pdf architecture and should be revisited in the new architecture where Typst and svg2pdf share more code.

Concretely, these changes should result in all rules listed in the Typst tracking issue being satisfied by svg2pdf. The only problems I could find were:

  • Name length for font names: I adjusted the code to trim them.
  • Maximum q nesting depth: I added a method to pdf-writer to track the depth (tracking it here would make the code uglier). I think that's generally useful. However, the validation itself happens in svg2pdf. When the nesting depth is too high, a new TooMuchNesting error is returned. In theory, we could use XObjects to reset the depth, but that is too much work right now.
  • Notdef glyphs: When they are found and PDF/A support is enabled, a new MissingGlyphs error is returned.

Notably, only the notdef rule actually checks for PDF/A mode because the other rules turn out to apply to all PDF standards as far as I can tell!

I would release pdf-writer 0.11.1 before merging this.

src/render/text.rs Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/render/mask.rs Show resolved Hide resolved
@LaurenzV
Copy link
Collaborator

LaurenzV commented Sep 27, 2024

I think there are a few more points that require attention:

  • Strings can't be longer than 32767 bytes -> Can't this happen if someone inputs a very long string? The text showing operator uses strings to display the glyphs, right?
  • Can't contain more than 8388607 indirect objects -> I guess this can be done on the Typst side?
  • 6.2.11.3.3: IIRC we don't write the WMode in the CMAP dictionary, should be an easy fix, though.

@laurmaedje
Copy link
Member Author

  • Strings: If I read the code correctly, you show each glyph with a separate invocation of the text showing operator
  • Objects: Yep
  • CMap: ah okay, good catch!

@LaurenzV
Copy link
Collaborator

Strings: If I read the code correctly, you show each glyph with a separate invocation of the text showing operator

True, I forgot about that. 😅

@laurmaedje laurmaedje merged commit 3d11ac1 into main Sep 30, 2024
4 checks passed
@laurmaedje laurmaedje deleted the pdfa branch September 30, 2024 13:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants