Re: [Matplotlib-users] stix fonts don't work with ghostscript

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 <md...@st...> 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