ENH: try to use unicode charmap before ADOBE_STANDARD in textpath #8286
Conversation
This will allow a wider range of glyphs to be exported. Closes matplotlib#8280
There was a problem hiding this comment.
While working on improving usetex support in mplcairo, I realized why this won't work (at least as is).
In usetex mode, the SVG backend gets a list of (fontpath, glyph-index) from dviread and passes them to textpath to generate the glyph outlines that get embedded into the SVG file. However, the indices in the dvi file (and thus returned by dviread) correspond to the "native" charmap in the font file, which, for pfb fonts (e.g. computer modern), is an Adobe mapping. The Unicode charmaps are actually "fake" charmaps synthesized on-the-fly by FreeType. In particular, they do not include ligatures (which after all do not correspond to Unicode codepoints).
For example, one can try text(.5, .5, "ff", usetex=True); savefig("/tmp/test.svg") ("ff" is a ligature at position 11 of the "native" charmap); with this PR one gets
/home/antony/src/extern/matplotlib/lib/matplotlib/textpath.py:391: RuntimeWarning: Glyph 11 missing from current font.
glyph0 = font.load_char(charcode, flags=ft2font_flag)
and the ff ligature is not included (because, with the PR, one tries instead to load the character at Unicode codepoint 11, which is not a printable character).
|
@anntzer Is this salvageable? If you think not feel free to close. |
|
Let's keep this open while I figure out whether #8415 works better. |
|
I think this has been superseded by #12928 (which owes much to this PR, thanks :)). |
|
"Programming by doing it badly and annoying someone else enough to do it right" ;) |
|
I'm very easily annoyable... :) |
This will allow a wider range of glyphs to be exported.
Closes #8280
This needs some tests and an understanding of why the adobe mapping was used to begin with.