Implement multi-font embedding for PDF Backend #20804
Open
+737
−117
Conversation
3 of 7 tasks
ac118a7
to
d43551f
4 of 7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
PR Summary
Adding on to the changes from the original PR: #20740, this PR modifies the layout of FT2Font to allow multiple fonts to work with the PDF backend.
Agg backend is simpler to work with, since things like kerning are set within FT2Font, and all we really needed was a bitmap from it. However, for the PDF backend, we need to extract each glyph from a (possibly) parent FT2Font.
To tackle this, I've implemented a caching layer for the parent object, allowing us to directly get the relevant FT2Font which has a certain glyph. Bits and pieces behind how PDF backend handles fonts is also modified.
With this, we can successfully generate Type 3 and Type 42 subsetted multi-font PDFs:
type3_fallback.pdf
type42_fallback.pdf
Test Script:
Builds on: #20740, Fixes #18883, #15260
PR Checklist
pytest
passes).flake8
on changed files to check).flake8-docstrings
and runflake8 --docstring-convention=all
).doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).