You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rework mapping of dvi glyph indices to freetype indices.
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 (`_index_dvi_to_freetype`) to perform
this mapping, 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. Note that this API is intentionally kept private for now
(even though it is used by textpath) and the old APIs are not deprecated
yet; I intend to wait until {xe,lua}tex support is actually merged to do
so, to avoid possible future back-and-forth changes on the public APIs.
In case (A), this PR also improves on the detection of the native
charmap, which was previously detected via heuristics
(`_select_native_charmap`), but is now read by directly accessing the
Type 1 font "encoding vector".
0 commit comments