Re: Bug in eps output of matplotlib

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 limita
 tion 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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com