Fix loading of Type1 "native" charmap. #29843
Merged
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
a0278f6 to
662d675
Compare
5 tasks
timhoffm
reviewed
Apr 1, 2025
timhoffm
approved these changes
Apr 2, 2025
QuLogic
reviewed
Apr 3, 2025
5 tasks
Type1 fonts have a "native" charmap (mapping of indices to glyphs
(\*)), which is simply the order in which glyphs are physically listed
in the file (see section 2.2 of Type1 reference linked below); this
charmap needed when decoding dvi files for usetex mode (as dvi represent
glyphs with these indices). Usually, this charmap is tagged as
"ADOBE_STANDARD" or "ADOBE_CUSTOM", which is the heuristic we previously
used to load it, but it is unclear to me whether this is guaranteed
(reference section 10.3), and FreeType may supply its own reencodings
(it already does so to try to provide a unicode charmap). Instead,
directly read and return the encoding vector via FreeType's
Type1-specific API. (The choice to return an mapping of Type1 indices
to FreeType-internal indices, rather than Type1 indices to glyph names,
is motivated by upcoming changes for {xe,lua}tex support, which also use
FreeType-internal indices.)
Type1 reference:
https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf
(\*) Not all glyphs correspond to a unicode codepoint (e.g. a font can
contain arbitrary ligatures that are not representable in unicode),
which is (one of the reasons) why fonts provide their own indexing
methods.
QuLogic
approved these changes
Apr 15, 2025
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.
Type1 fonts have a "native" charmap (mapping of indices to glyphs (*)), which is simply the order in which glyphs are physically listed in the file (see section 2.2 of Type1 reference linked below); this charmap needed when decoding dvi files for usetex mode (as dvi represent glyphs with these indices). Usually, this charmap is tagged as "ADOBE_STANDARD" or "ADOBE_CUSTOM", which is the heuristic we previously used to load it, but it is unclear to me whether this is guaranteed (reference section 10.3), and FreeType may supply its own reencodings (it already does so to try to provide a unicode charmap). Instead, directly read and return the encoding vector via FreeType's Type1-specific API. (The choice to return an mapping of Type1 indices to FreeType-internal indices, rather than Type1 indices to glyph names, is motivated by upcoming changes for {xe,lua}tex support, which also use FreeType-internal indices.)
Type1 reference:
https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf
(*) Not all glyphs correspond to a unicode codepoint (e.g. a font can contain arbitrary ligatures that are not representable in unicode), which is (one of the reasons) why fonts provide their own indexing methods.
(This is tested by the same test as #12928.)
PR summary
PR checklist