Simplify and unify character tracking in pdf and ps backends. #15320
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6 tasks
|
missing-references.json is still large. Probably this needs a rebase? |
|
rebased |
timhoffm
reviewed
Sep 22, 2019
| @@ -16,11 +16,43 @@ def _cached_get_afm_from_fname(fname): | |||
| return AFM(fh) | |||
|
|
|||
|
|
|||
| class CharacterTracker: | |||
| def __init__(self): | |||
There was a problem hiding this comment.
I would love to see a bit more documentation on the class itself and its public methods.
6 tasks
timhoffm
approved these changes
Nov 9, 2019
Instead of trying to resolve font paths to absolute files and key off by inode(!), just track fonts using whatever names they use, and simplify used_characters to be a straight mapping of filenames to character ids (making the attribute private -- with a backcompat shim) at the same time). The previous approach would avoid embedding the same file twice if it is given under two different filenames (hardlinks to the same file...), but it would fail if the user passes a relative path, chdir()s to another directory, and passes another different font with the same filename, because of the lru_cache(). None of these seem likely to happen in practice, and in any case we can cover most of it by making the font paths absolute before passing them to FreeType (which is going to open the file anyways, so the cost of making them absolute doesn't matter).
|
I had a closer look at this implementation. I've tested the code in the scenario from #15629 (linked fonts with different file names, e.g. arial.ttf -> Arial.ttf). There is still one place where the real fonts are used: font_manager.get_font() In this case, all the characters are missing: |
6 tasks
|
Superseded by #15686. |
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.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of trying to resolve font paths to absolute files and key off by
inode(!), just track fonts using whatever names they use, and simplify
used_characters to be a straight mapping of filenames to character ids
(making the attribute private -- with a backcompat shim) at the same
time).
The previous approach would avoid embedding the same file twice if it is
given under two different filenames (hardlinks to the same file...), but
it would fail if the user passes a relative path, chdir()s to another
directory, and passes another different font with the same filename,
because of the lru_cache(). None of these seem likely to happen in
practice, and in any case we can cover most of it by making the font
paths absolute before passing them to FreeType (which is going to open
the file anyways, so the cost of making them absolute doesn't matter).
missing_references.json needs to be regenerated due to the missing reference to the private CharacterTracker class; to avoid changes in order in missing_references.json creating needless diffs, this goes on top of #15321
PR Summary
PR Checklist