Hi Michael! Thanks a lot, I've applied the changes to mathtext in my installation and it works now!
Bernhard On Feb 1, 2008 8:16 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > 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
