[Matplotlib-users] Font problems with generated EPSs

This was originally on Matplotlib-users, but -devel seems more appropriate.

Darren Dale <dd55@...143...> writes:

Darren Dale wrote:

Darren Dale wrote:

Hi,

I'm trying to use matplotlib solely for my plotting needs.
Problem is, the fonts are embedded in each EPS file, and
when I import several plots (I have tens of them...) into a
single Latex, the resulting file is HUGE.

Any suggestions?

There are currently two options: you can either set ps.useafm = True, or
you can set text.usetex = True in your rc settings. Since you are
importing figures into latex, I suggest the usetex option. That way,
your figure fonts can be the same as your text fonts. You'll take a bit
of a speed hit with the latter option, but in my opinion, its the only
way to go for generating plots for publication.

When using tex for font rendering I noticed that parts of the text are
not converted to polygons but embedded as bitmaps. That makes the files
big again. Do you now how to avoid that? E.g. using the r'C\_\{12\} will
produce two images for the numbers and a polygon for the 'C'.

I made a wiki entry a while back about how to work around this problem,
but it looks like someone deleted it in mid-November, and I dont have a
backup copy. My solution requires ghostview and xpdf, which is why we
dont include it in mpl by default.

Thanks!
Has using pdflatex for tex labels been considered? Or is that too much
dependency? It could possibly even be faster.

I'm guessing pdflatex is provided by default by every up-to-date latex installation out there.

I believe that the latest version of tetex even uses the same binary for latex and pdflatex.

However, mpl uses a latex package called PSFrag to render the text in an intermediate postscript file, which is not compatible with pdflatex. Unfortunately, if you embed that intermediate postscript file in a new document, the text will frequently be upside down, because PSFrag uses some commands that are illegal in embedded documents. So by default, mpl uses ghostscript to "distill" the intermediate postscript file, converting the fonts to outlines and circumventing the problem.

I attach a patch against matplotlib 0.85 that uses a picture environment to position text instead of using psfrag.

It isn't complete, and therefore probably shouldn't be applied just yet, but may be a useful starting point. In particular, I haven't taken out the distill code, but suspect that it could be replaced by using the right options to dvips.

If I had the right dvips command instead of the ghostscript distilling process, would this result in a legal eps file? Ie is this worth pursuing?

The code I posted last time replaces the distilling step with a ridiculous renormalization step (converting the file to pdf using ghostscript, and then converting back to eps using xpdf) which generates a new eps file that can be embedded in another document. This seems to be pretty robust, convoluted though it is. I generated all the figures in my dissertation this way.

A side note, if you intend to compile a document with pdflatex, you can convert mpl's eps files with epstopdf, which is included in recent versions of TeTeX.

My .tex file does seem to be able to be compiled with pdflatex - if you include a .pdf rather than .eps graphic. Whether this is useful or not, I'm not sure.

Chris

ps While doing this, I noticed that \paperheight is set to the paper width, and vice versa.

mpl-pic1.patch (1.94 KB)

···

On Wednesday 07 December 2005 08:41, Christian Kristukat wrote:

On Tuesday 06 December 2005 10:03, Christian Kristukat wrote:

On Tuesday 06 December 2005 09:10, Alex Gontmakher wrote:

Hi Chris,

This was originally on Matplotlib-users, but -devel seems more appropriate.

[...]

Darren Dale <dd55@...143...> writes:
> However, mpl uses a latex package called PSFrag to
>render the text in an intermediate postscript file, which is not
> compatible with pdflatex. Unfortunately, if you embed that intermediate
> postscript file in a new document, the text will frequently be upside
> down, because PSFrag uses some commands that are illegal in embedded
> documents. So by default, mpl uses ghostscript to "distill" the
> intermediate postscript file, converting the fonts to outlines and
> circumventing the problem.

I attach a patch against matplotlib 0.85 that uses a picture
environment to position text instead of using psfrag.

It isn't complete, and therefore probably shouldn't be applied just yet,
but may be a useful starting point. In particular, I haven't taken out
the distill code, but suspect that it could be replaced by using the
right options to dvips.

If I had the right dvips command instead of the ghostscript distilling
process, would this result in a legal eps file? Ie is this worth pursuing?

Here is a post from way back describing the embedding issue:
http://sourceforge.net/mailarchive/message.php?msg_id=12030448

"PSFrag was not designed to do what I am trying to do:
generate an eps file that can later be embedded in a document. It uses a
number of PostScript operators that are illegal in an eps file: setglobal,
statusdict and userdict. Here is the blurb from PostScript Language
Reference, Second Edition, Appendix I: setglobal disrupts page independence
and nesting of included documents. [...] Creation and modification of global
objects are uneffected by save-restore operators."

So, to answer your question, if you need to use a PostScript operator that is
illegal in an eps file, it is not worth pursuing. I think your patched
backend_ps.py still generates a .tex file that uses the PSFrag package, which
will unavoidably end up using illegal PostScript operators. Is this correct?

Darren

···

On Tuesday 03 January 2006 10:48, Chris Walker wrote: