Well, this is a really good puzzle. I think the difference in ghostscript versions is a red herring. Ghostscript can be used to "distill" eps files, and therefore could be part of the production pipeline, but only if you set the ps.usedistiller rcParam.
The problem in the broken .eps file you sent me was that it was including two STIXGeneral fonts, one with the characters produced by the mathtext engine, and one with the characters produced by the regular text engine. Since they both had the same Postscript name, the Postscript interpreter presumably got confused and didn't know where to get characters from. Why was this happening? I have a theory. The mathtext engine looks for the fonts directly, since it knows they should be in the matplotlib installation directory, whereas the regular text engine was looking up the fonts through a more complex "font-finding" algorithm that finds fonts in a number of places on the system. It's possible (and this is a huge guess) that on your "broken" machine, you have the STIXGeneral font installed somewhere other than the matplotlib installation directory (~/.fonts or /usr/share/fonts or something). Matplotlib assumes that if two fonts have different paths that they are different fonts and *boom* you get two fonts with the same name in the Postscript file. All that is just conjecture about your situation, but I was able to reproduce it here by copying the STIX fonts to ~/.fonts. I have fixed mathtext so it uses the font-finding mechanism, so that whenever anyone asks for "STIXGeneral", it should always get the same thing. That has been fixed in SVN r4928. The problem with Ps+Type42+STIXGeneral still persists. I'm pretty certain this is due to the size of the font file. For that reason, Type3 is just a better option anyway, so I don't consider it a high priority -- but if you have a use case where it really matters, certainly let me know. Cheers, Mike Bernhard Voigt wrote: >> Well, I was able to fix the spacing problem with PDF+Type42. That has >> now been fixed in SVN r4915 (and on the maintenance branch). It's a >> simple patch that I'll forward to you. > > Thanks, that works! > >>> At home, using another gs version (8.15.0, instead of 8.15.2) also the >>> eps is ok with ps.fonttype 3, though the one with fonttype 42 is still >>> erroneous. >> It's always fun when an external dependency breaks something... ;) I >> only have the fairly old gs 7.07, and it seems to always work with type >> 3, and sometimes break with type 42. Can you do me a favor to save me >> the trouble of having to install a bunch of versions of ghostscript? >> Can you send me an eps of the same plot produced through gs 8.15.0 and >> 8.15.2? I hope that by examining the differences there will be some >> clue as to the breakage. > > Attachted are plots produced with type 3. I thought it's the viewer > which produces the problems and gs is not involved in writing these > files, though. Isn't the ps backend producing the ps files on its own? > > Well, but somehow there is a difference in the eps files. I've on both > machines the same matplot version, but as I said, the eps produced at > home with type3 is ok, it's also ok viewing it a work with the newer > gs interpreter. The other way around does not work, files produced at > work produce errors when viewing on both machines. > > Hope the files are helpflull! Bernhard > > >> Thanks, >> Mike >> >>> Thanks! Bernhard >>> >>> >>> On Jan 31, 2008 4:45 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >>>> Can you send the source of your plot, and also your matplotlibrc file? >>>> >>>> Bernhard Voigt wrote: >>>> >>>> -- >>>> >>>> Michael Droettboom >>>> Science Software Branch >>>> Operations and Engineering Division >>>> Space Telescope Science Institute >>>> Operated by AURA for NASA >>>> >> -- >> >> Michael Droettboom >> Science Software Branch >> Operations and Engineering Division >> Space Telescope Science Institute >> Operated by AURA for NASA >> -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
