I believe the bug actually is in matplotlib, and recent ghostscript versions fail only because they have become stricter over time. The TTF-to-Postscript font conversion library in matplotlib (ttconv) was hard-coded to use the "Standard" Postscript encoding (which defines the set of glyphs available for use), and "Standard" doesn't include the "/minus" sign. This confuses ghostscript when it tries to convert a Type 3 Postscript font to a Type 3 PDF font. Since detecting the correct "built-in" encoding to use when converting an arbitrary TTF file is rather tricky (and matplotlib can use some pretty esoteric Unicode characters when drawing math expressions), my workaround is to create a custom encoding for each font, containing only the glyphs actually being used. Postscript has a limitation of 255 glyphs per font in a custom encoding, but in practice it should be difficult to hit this. Surprisingly (to me at least), using a wacky arbitrary encoding doesn't break the Find/R!
!
eplace and accessibility functions on the resulting PDF file.
So, this is now fixed in SVN trunk, I believe. As a workaround for released versions of matplotlib, you can set ps.fonttype to 42 which sidesteps the whole Type 3 font subsetting/encoding issue. At least on my machine, I had no trouble converting a PS file with Type 42 fonts to a PDF with ps2pdf/gs 8.70.
Thanks for your help tracking this down.
Mike