Rework mapping of dvi glyph indices to freetype indices. #29829
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
7a760d1 to
45eae37
Compare
5 tasks
99185ed to
48be1ca
Compare
QuLogic
reviewed
Apr 18, 2025
QuLogic
approved these changes
Apr 18, 2025
5 tasks
In 89a7e19, an API for converting "dvi glyph indices" (as stored in a dvi file) to FreeType-compatible keys (either "indices into the native charmap" or "glyph names") was introduced. It was intended that end users (i.e., backends) would check the type of `text.glyph_name_or_index` ((A) int or (B) str) and load the glyph accordingly ((A) `FT_Set_Charmap(native_cmap); FT_Load_Char(index);` or (B) `FT_Load_Glyph(FT_Get_Name_Index(name));`); however, with the future introduction of {xe,lua}tex support, this kind of type checking becomes inconvenient, because {xe,lua}tex's "dvi glyph indices", which are directly equal to FreeType glyph indices (i.e. they would be loaded with `FT_Load_Glyph(index);`), would normally also be converted to ints. This PR introduces a new API (`Text.index`) that performs this mapping (via the new `DviFont._index_dvi_to_freetype`), always mapping to FreeType glyph indices (i.e. one can always just call `FT_Load_Glyph` on the result). To do so, in case (A) it loads itself the native charmap (something the end user needed to do by themselves previously) and performs the cmap-to-index conversion (`FT_Get_Char_Index`) previously implicit in `FT_Load_Char`; in case (B) it performs itself the name-to-index conversion (`FT_Get_Name_Index`). When {xe,lua}tex support is introduced in the future, `_index_dvi_to_freetype` will just return the index as is. The old APIs are not deprecated yet, as other changes will occur for {xe,lua}tex support (e.g. font_effects will go away and be replaced by `.font.effects`, as {xe,lua}tex don't store that info in the pdftexmap entry), and grouping all API changes together seems nicer (to only require a single adaptation step by the API consumer).
story645
reviewed
May 6, 2025
Comment on lines
+649
to
+651
| # - if no ".enc" file is specified, then the font must be a Type 1 | ||
| # font, and dvi indices directly index into the font's CharStrings | ||
| # vector. |
There was a problem hiding this comment.
just checking but is this why this step is no longer needed: index = t1_encodings[font][glyph_name_or_index]
There was a problem hiding this comment.
This still happens at the bottom: self._encoding = face._get_t1_encoding_vector() (likewise caching the value of the encoding vector, but this now occurs on the DviFont object) then return self._encoding[idx].
story645
reviewed
May 7, 2025
| if self._encoding is None: | ||
| psfont = PsfontsMap(find_tex_file("pdftex.map"))[self.texname] | ||
| if psfont.filename is None: | ||
| raise ValueError("No usable font file found for {} ({}); " |
There was a problem hiding this comment.
Can you please add a test for coverage?
There was a problem hiding this comment.
This gets further refactored in the followup PR #29939 into DviFont.path, which does have test coverage (because it is also used elsewhere -- see https://app.codecov.io/gh/matplotlib/matplotlib/pull/29939#4c703021fcf83cd901550e2c525d78ae-R733). I can move code around so that the intermediate stage also has full coverage if you prefer, but this split seems more logical to me.
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.
In 89a7e19, an API for converting "dvi glyph indices" (as stored in a dvi file) to FreeType-compatible keys (either "indices into the native charmap" or "glyph names") was introduced. It was intended that end users (i.e., backends) would check the type of
text.glyph_name_or_index((A) int or (B) str) and load the glyph accordingly ((A)FT_Set_Charmap(native_cmap); FT_Load_Char(index);or (B)FT_Load_Glyph(FT_Get_Name_Index(name));); however, with the future introduction of {xe,lua}tex support, this kind of type checking becomes inconvenient, because {xe,lua}tex's "dvi glyph indices", which are directly equal to FreeType glyph indices (i.e. they would be loaded withFT_Load_Glyph(index);), would normally also be converted to ints.This PR introduces a new API (
Text.index) that performs this mapping (via the newDviFont._index_dvi_to_freetype), always mapping to FreeType glyph indices (i.e. one can always just callFT_Load_Glyphon the result). To do so, in case (A) it loads itself the native charmap (something the end user needed to do by themselves previously) and performs the cmap-to-index conversion (FT_Get_Char_Index) previously implicit inFT_Load_Char; in case (B) it performs itself the name-to-index conversion (FT_Get_Name_Index). When {xe,lua}tex support is introduced in the future,_index_dvi_to_freetypewill just return the index as is.The old APIs are not deprecated yet, as other changes will occur for {xe,lua}tex support (e.g. font_effects will go away and be replaced by
.font.effects, as {xe,lua}tex don't store that info in the pdftexmap entry), and grouping all API changes together seems nicer (to only require a single adaptation step by the API consumer).PR summary
PR checklist