stix fonts don't work with ghostscript

Bernhard Voigt wrote:

Hi Michael,

attatched is my matplotlibrc file.

The plot was from some data, but i principle it was crated like that:
import pylab as p
import numpy as n

p.hist(-1 * n.log10(n.random.uniform(size=10000)), 40)
p.xlabel('\\mathrm\{log\_\{10\}\(E/GeV\)\}')
p.ylabel('counts')
p.title('energy spectrum')
p.savefig('foo.pdf')
p.savefig('foo.eps')

I can report that the rendering of the pdf file is correct, when I set
the pdf.fonttype to 3. Than everything looks good :slight_smile:

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.

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... :wink: 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.

Thanks,
Mike

···

Thanks! Bernhard

On Jan 31, 2008 4:45 PM, Michael Droettboom <mdroe@...86...> 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

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... :wink: 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

foo_gs_8_15_0.eps (26.4 KB)

foo_gs_8_15_2.eps (31.1 KB)

···

Thanks,
Mike

> Thanks! Bernhard
>
>
> On Jan 31, 2008 4:45 PM, Michael Droettboom <mdroe@...86...> 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

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... :wink: 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 <mdroe@...86...> 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

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 <mdroe@...86...> 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... :wink: 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 <mdroe@...86...> 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