very large postscript

Next problem .... interactive running, using the TkAgg

    > backend, from ipython -pylab draws pretty graphs -- very
    > impressive -- and I can save to .png fine. But saving to
    > postscript gives a very large file, which moreover seems
    > to be corrupted. Editing the .matplotlibrc file to use the
    > PS backend directly & starting up ipython again gives the
    > same very large, corrupt, PS file.

As for the corrupt file, I refer you to Darren's post.

As for the large PS file, the size is the result of embedding truetype fonts
directly into the postscript file. The problem is that we currently embed the
entire font file rather than just the needed glyphs. This is a known
problem but we haven't solved it yet. Please file a bug on the
sourceforge site to help remind us...

There is a workaround. You can set the rc param

ps.useafm : True # use of afm fonts -- breaks mathtext but results in small files

to use native postscript fonts. This will break postscript unicode
and mathtext, but suffices for most uses. In this case, you use
native postscript fonts and don't get the obscene file sizes.

Hope this helps,
JDH

Thought I'd summarize my experiences. They may result from a messed up installation, but could be useful for others -- Bradley Minch, using 10.2.8, seems to have had my initial problem, #I below.
Excuse the overlong email here.
Many thanks to Darren Dale for helping me out.

Setup:
matplotlib 0.80, ipython 0.6.13, readline.so [from www.pycs.net/bbum/2004/1/21/readline.so.gz]
  zlib, libpng, tk_inter8.4, freetype 2.1.9 [produces libfreetype.6.3.7.dylib], wx-2.6-mac-unicode,
  standard Panther Apple Python 2.3, updated to MacPython,
  scipy 0.3.2 [from http://cbis.anu.edu.au/misc/SciPy_complete-0.3.2.mpkg.zip]
Numeric 23.1, OS X 10.3.9

Running with TkAgg backend set in .matplotlibrc

1. Original problem:
First time I did
from pylab import * (or ipython -pylab)

got error while font_manager was trying to build the ttffont.cache...

   File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 347, in ttfFontProperty
   size = str(float(font.get_fontsize()))
  AttributeError: get_fontsize

Now, when building the ttf cache, font_manager searches for TrueType fonts.
1. in the matplotlib data directory /System/Library/Frameworks/Python.framework/Versions/2.3/share/matplotlib
2. In the normal Mac places
/Library/Fonts/, /System/Library/Fonts,/Network/Library/Fonts, ~/Library/Fonts

Tracked this problem down to the font VT102Font that I had in ~/Library/Fonts.
Moved VT102Font to (new directory) ~/SuspectFonts off the font path.

Problem 1 solved! from pylab import * now happily built a ~/.ttffont.cache for me.

2. Next problem -- absurdly large, corrupted, PS files.

Ran this script that produces simple plots, with axes labelled (by default) with sans-serif numbers.
dt = 0.01
t = arange(0,10,dt)
subplot(211)
s = sin(t)
plot(t,s)
subplot(212)
c = cos(t)
plot(t,c)

savefig('/Users/agn/sincos.png')
  -- produced a nice file ~28KB in size
savefig('/Users/agn/sincos.ps')
  -- produced a file of 4.6MB.
  Trying to view this file using Apple preview, or converting it to pdf with ps2pdf (ps2pdf13, v1.3, 21Feb2002) or Apple pstopdf gave an error. E.g. ps2pdf sincos.ps gave:

Error: /invalidfont in -dict-
Operand stack:
    LucidaGrande --dict:10/14(L)-- Font LucidaGrande --dict:10/14(L)-- LucidaGrande

Darren Dale sorted me out here. The default sans-serif font used to label the axes is the first font in the san-serif line (about line 113) in the .matplotlibrc startup file. The default .matplotlibrc gives LucidaGrande as that default font. LucidaGrande.dfont is an Apple standard font living in /System/Library/Fonts.
He suggested that I put Bitstream Vera Sans as the first font on the san-serif line in .matplotlibrc, so that this font, which comes with matplotlib, and lives in /System/Library/Frameworks/Python.framework/Versions/2.3/share/matplotlib is used as the default sans-serif font instead.

Problem 2 solved. savefig('/Users/agn/sincos.ps') now gives a 176 KB ps, that reduces to a 36KB pdf. Perfectly OK now.

Suspected same problem would arise for other families, so put Bitstream Vera Serif as the default serif font, & Bitstream Vera Sans Mono as the default monospace font.

3. John Hunter suggested that problem 2 might be solved if I were to modify line 180 of .matplotlibrc to set
  ps.useafm : True
This should give smaller Ps files at the cost of breaking mathtext (which incidentally *does* (almost completely) work for me with ps.useafm : False).
Unfortunately, setting ps.useafm true doesn't work for me. Now if ps.useafm is True, font_manager only makes a cache -- .afmfont.cache -- when you first try to save to PS. I have at present the problem that font_manager is falling over when trying to make this cache. One of the Chinese-type opentype (.otf) fonts --- /System/Library/Fonts/ヒラギノ明朝 Pro W3.otf -- or in hex
/System/Library/Fonts/\xe3\x83\x92\xe3\x83\xa9\xe3\x82\xad\xe3\x82\x99\xe3\x83\x8e\xe6\x98\x8e\xe6\x9c\x9d Pro W3.otf
causes an infinite loop with 'Key error converting in AFM' in afm.py, when trying to parse the header.

Quite a few fonts are in 'seen', --
{'pbkd8a.afm': 1, 'pagd8a.afm': 1, 'pbkl8a.afm': 1, 'ptmri8a.afm': 1, 'pncb8a.afm': 1, 'phvbo8a.afm': 1, 'phvb8an.afm': 1, 'phvro8an.afm': 1, 'ptmb8a.afm': 1, 'pcrro8a.afm': 1, 'pcrb8a.afm': 1, 'pplr8a.afm': 1, 'pzdr.afm': 1, 'cmsy10.afm': 1, 'phvlo8a.afm': 1, 'cmr10.afm': 1, 'phvb8a.afm': 1, 'phvl8a.afm': 1, 'pncri8a.afm': 1, 'pagdo8a.afm': 1, 'putri8a.afm': 1, 'pzcmi8a.afm': 1, 'ptmbi8a.afm': 1, 'phvro8a.afm': 1, 'putr8a.afm': 1, 'phvbo8an.afm': 1, 'pcrr8a.afm': 1, 'putbi8a.afm': 1, 'pcrbo8a.afm': 1, 'cmtt10.afm': 1, 'pplb8a.afm': 1, 'pbkdi8a.afm': 1, 'pagk8a.afm': 1, 'pncr8a.afm': 1, 'putb8a.afm': 1, 'psyr.afm': 1, 'pagko8a.afm': 1, 'pplbi8a.afm': 1, 'pbkli8a.afm': 1, 'pncbi8a.afm': 1, 'cmmi10.afm': 1, 'ptmr8a.afm': 1, 'pplri8a.afm': 1, 'cmex10.afm': 1, 'phvr8a.afm': 1, '\xe3\x83\x92\xe3\x83\xa9\xe3\x82\xad\xe3\x82\x99\xe3\x83\x8e\xe6\x98\x8e\xe6\x9c\x9d Pro W3.otf': 1, 'phvr8an.afm': 1}

so have presumably been successfully parsed, except for this .otf font.

Haven't sorted this problem out yet. I suppose I could try removing the East Asian fonts from the system folder, or changing font_manager so it does not read them in.

4. Conclusion: For me, the only fonts that work are the BitStream Vera Fonts supplied with matplotlib. Not ideal, because they do do not include italic, cursive, or fantasy fonts (although they do include an *oblique* sans serif font). But this is sufficient to make matplotlib work for most practical purposes, especially as mathtext does work (though ps2pdf can't convert the ps fonts to pdf; Apple pstopdf (used by Preview) must be used)

Again, many thanks to Darren Dale and also to John Hunter and Fernando Perez for their replies.

George Nurser.