# help...

This is the continuation of an exchange in which Fernando reported a
problem when viewing eps figures generated by mpl and included in a
pdf file generated by latex.

> In acroread the fonts on page 4 look like crap, but if I
> print it, it looks fine. So the problem looks like a
> mismatch between acroread and the TTF.

I took the plunge and made a new rc param

ps.useafm : False

if True, the ps backend will fall back on old font handling, using afm
files and not embedding true type. This of course breaks mathtext,
but does result in files that are small, and they may work better in
acroread when converted to PDF via latex. Here is simple_plot made
with useafm = False and useafm = True.

peds-pc311:~/python/projects/matplotlib> ls -l *.ps
-rw-rw-r-- 1 jdhunter jdhunter 7137 Feb 23 15:36 afm.ps
-rw-rw-r-- 1 jdhunter jdhunter 144234 Feb 23 15:35 ttf.ps

It appears to pass backend driver, though I didn't visually check
every output. It would be nice to extend this approach to allow the
user to use afm for everything but mathtext, if desired, as well as to
embed only the individual truetype glyphs as we've discussed before,
but this is a start. I didn't use the state caching with the afm
fonts since this is a system Jochen created and I don't want to break
anything, so Jochen you may want to take a look and clean it up. I'm
pretty sure I didn't break anything -- just added new functionality
that might be able to be done more efficiently.

Fernando, on another note, I believe the Cairo backend generates PS,
which you could also try. I haven't looked at it.

JDH

John Hunter wrote:

"Paul" == Paul Barrett <barrett@...31...> writes:

This is the continuation of an exchange in which Fernando reported a
problem when viewing eps figures generated by mpl and included in a
pdf file generated by latex.

Thanks John, I really appreciate you working on this right now. Unfortunately I'm scrambling to finish this talk, so I don't have time to switch matplotlib versions right now across my desktop _and_ laptop. Don't switch horses while crossing the river and all that.

But next week I'll look into the fix. For now, switching to pngs works OK, they look fine (if not perfect) under Acroread, which is all I need. As a side note, even if these print fine, since I use acroread for a laptop-based presentation via a projector, that doesn't do me much good

Anyway, thanks again to John and Paul for tackling this at my request. I'll survive with the png solution for now, and will look into the new PS option next week.

While on that topic: would it be possible/sensible to support at least sub/superscripts and symbols in the plain PS backends? Gnuplot allows you to switch fonts and embed symbols with the native PS symbol font, which has the advantage of producing tiny PS files. Here's an example of some old code of mine:

tit_s = "N_{nod}=%s, {/Symbol e}=%1.1e, N_{blocks}=%s"
title = tit_s % (self.nnod,self.cutoff,self.nkeys())

Not perfect, and eps-specific, but quite handy for making small EPS files with basic mathematical notation.

I suggest this because right now, as far as I'm concerned, the mathtext support is in practice of little use. Since the _whole_ string has to be $-$ bracketed, putting text with a bit of math doesn't work well. Most real-world usage of symbols in plot labels is of this kind, rather than one big equation. I know about using \textrm for text, but the resulting spacing is so ugly that it's really not worth using.

Another option would be to get support for mathtext in substrings (e.g. r'Error for $\epsilon=1$' as a valid label). But I know that's hard. If you go down this road, for ease of parsing, you may want to require the beginning/end math markers to be , as latex allows (but doesn't enforce).

Anyway, I'm really grateful and don't want to sound like a whiner. With time, I'm sure we'll be able to work out all the remaining kinks of proper labeling for scientific plots with math in them in an optimal manner. And again, thanks for all the hard work so far.

Best,

f