In89a7e19, 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 oftext.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_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 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_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).

PR summary

PR checklist

• "closes #0000" is in the body of the PR description tolink the related issue
• new and changed code istested
• Plotting related features are demonstrated in anexample
• New Features andAPI Changes are noted with adirective and release note
• Documentation complies withgeneral anddocstring guidelines