Bug report

Bug summary

As in the title.

Code for reproduction

frompylabimport*rcParams["ps.fonttype"]=42figtext(.5,.5,"€");savefig("/tmp/euro.ps");close("all")figtext(.5,.5,"0€");savefig("/tmp/zeroeuro.ps");close("all")figtext(.5,.5,"$\sqrt{2}$");savefig("/tmp/sqrt.ps");close("all")

Actual outcome

Ineuro.ps the font is actually embedded as Type 3, not Type 42 (as can be checked by opening the file in a text editor).
Inzeroeuro.ps the font is correctly embedded as Type 42, but the euro sign fails to display correctly (we get a rectangular box instead).
sqrt.ps causes an error with the viewer (Error: /invalidfont in definefont).

Given that in all likelihood this has been broken for a loooooong time (as ttconv is rarely touched) it may be worth waiting for a decision on#18143 first before trying to fix this.

On the other hand, note that this also affects theps.fonttype = 3 case when rendering more than 255 characters, because we fall back to type 42 in that case (example below). By the spec, a type 3 font cannot contain more than 255 glyphs, but empirically, things work just fine for us, likely because we always refer to glyphs by glyph name rather than by glyph index? If we want to be super safe wrt. the spec, I guess we could split a >255-glyph font into multiple fonts and callsetfont as needed (we're positioning glyphs one at a time anyways).

importtextwrapfrompylabimport*figtext(0,.5,"\n".join(textwrap.wrap("".join(cforcinmap(chr,range(512))ifc.isprintable()))))savefig("/tmp/test.ps")

As a side point, it seems likely that type 42 embedding isalso broken for the pdf backend, per#12636...

Matplotlib version

• Operating system: linux
• Matplotlib version: master
• Matplotlib backend (print(matplotlib.get_backend())): ps
• Python version: 38
• Jupyter version (if applicable):
• Other libraries: