My lovely matplotlib EPS graphics are missing in my PDF
> files if I use dvipdfm. It looks (?) like they are included
> but then are blanked out afterwards. Any idea why? I have
> never had trouble with other EPS files.
We've seen a number of reports of problems in converting matplotlib
eps files -> pdf. To help us narrow the potential causes of the
problem, could you provide the results of --verbose-helpful with an
example script and rc file, as well as platform and version info for
latex, gs, and otherwise. Just give us as much information as you
can, what sequence of commands you are issuing and what versions of
each you are using. Nonstandard rc settings (usetex?) and so on.
matplotlib can be used in a lot of ways. If you submit a script and
an rc file (if it is different in any way than the default) and the
commands you are typing and some extra version info, then it helps
pare down the list of potential explanations for the problems you are
seeing.
Thanks,
JDH
Alan, are you using a mac? If so, I wonder if this is related to embedding the
native mac fonts. One user a while back reported having to change his font
settings in matplotlibrc to load the bitstream fonts instead of the apple
fonts.
···
On Friday 02 September 2005 10:00 pm, John Hunter wrote:
> My lovely matplotlib EPS graphics are missing in my PDF
> files if I use dvipdfm. It looks (?) like they are included
> but then are blanked out afterwards. Any idea why? I have
> never had trouble with other EPS files.
We've seen a number of reports of problems in converting matplotlib
eps files -> pdf. To help us narrow the potential causes of the
problem, could you provide the results of --verbose-helpful with an
example script and rc file, as well as platform and version info for
latex, gs, and otherwise. Just give us as much information as you
can, what sequence of commands you are issuing and what versions of
each you are using. Nonstandard rc settings (usetex?) and so on.
matplotlib can be used in a lot of ways. If you submit a script and
an rc file (if it is different in any way than the default) and the
commands you are typing and some extra version info, then it helps
pare down the list of potential explanations for the problems you are
seeing.
--
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd55@...163...
http://people.ccmr.cornell.edu/~dd55/
No. I'm on a PC. And although I in general understand
John's request for a script, I think the EPS file I provided
will be more helpful in pinning this down. It took me
a while to see it, but finally I got it.
If you look at the bounding box, it is outside all standard
paper sizes. Now it turns out that pdfwrite assumes a paper
size and clips outside that size. Thus my figure did not
show because it was clipped. This does not happen when one
uses dvips because the EPS file is handled *as* an EPS
*before* creation of the PDF file.
Lesson (I think): matplotlib should create its EPS files so
that they have bounding boxes inside a4 width and letter
paper height boundaries, or people will have trouble with
their standard configurations of some standard tools.
Alan Isaac
PS I belive the matplotlib EPS files are written with
a superfluous gsave (just search for 'gsave' and you'll find
it in the file where it should not be), but this is not the
source of my problem.
···
On Fri, 2 Sep 2005, Darren Dale apparently wrote:
are you using a mac?
I have wondered why the origin of the bbox was shifted in eps files, but it
shouldn't matter. Seeing as how dvips, ps2pdf, and epstopdf all work as
expected, it sounds like a dvipdfm bug to me.
I don't think its a good idea to limit the size of eps figures. At some point,
I will make eps files that are larger than A4 for use in posters.
Darren
···
On Saturday 03 September 2005 1:14 am, Alan G Isaac wrote:
On Fri, 2 Sep 2005, Darren Dale apparently wrote:
> are you using a mac?
No. I'm on a PC. And although I in general understand
John's request for a script, I think the EPS file I provided
will be more helpful in pinning this down. It took me
a while to see it, but finally I got it.
If you look at the bounding box, it is outside all standard
paper sizes. Now it turns out that pdfwrite assumes a paper
size and clips outside that size. Thus my figure did not
show because it was clipped. This does not happen when one
uses dvips because the EPS file is handled *as* an EPS
*before* creation of the PDF file.
Lesson (I think): matplotlib should create its EPS files so
that they have bounding boxes inside a4 width and letter
paper height boundaries, or people will have trouble with
their standard configurations of some standard tools.
I have wondered why the origin of the bbox was shifted in
eps files, but it shouldn't matter.
I agree is should not matter. But it does for GhostScript's
pdfwrite.
Seeing as how dvips, ps2pdf, and epstopdf all work as
expected, it sounds like a dvipdfm bug to me.
If it is a bug (and I also believe it is), it's a pdfwrite
bug, assuming that pdfwrite should know how to produce
encapsulated PDF, which has been treated as the case by many
people for many years.
I don't think its a good idea to limit the size of eps
figures. At some point, I will make eps files that are
larger than A4 for use in posters.
As you said, it should not matter.
And it will make pdfwrite work as expected.
Cheers,
Alan Isaac
···
On Sat, 3 Sep 2005, Darren Dale apparently wrote: