Bug#428014: Inclusion of large eps files with dvipdfm
On Fri, 22 Jun 2007, Frank Küster wrote:
I tested Dan's suggestion: replacing -dEPSCrop in the config file with
-dDEVICEWIDTHPOINTS=500000 -dDEVICEHEIGHTPOINTS=500000
solves the problem for me.
What do you think?
That seems like a reasonable solution.
I'm not sure whether we need even more "0"s, or whether this would again
cause problems elsewhere (and be it only performance).
There are probably enough zeros.
On Fri, 22 June, 2007, Hartmut Henkel wrote:
dvipdfmx works substantially different and much better than dvipdfm. One
should try to check if all these problems persist in dvipdfmx, and if
not suggest to use this instead of ancient dvipdfm. If gs works in
standard eps/crop mode it should be just right.
Dvipdfm and dvipdfmx behave the same way in this regard. The behavior is
not a bug, but is intentional. When I wrote the graphic inclusion code, I
had one design goal: Dvipdfm should behave the same way as dvips when run
on the same DVI file. In other words, dvipdfm uses the same
interpretation of the coordinate system interpretation of what's in the
DVI file is contrained by the dvips interpretation. This constraint
requires this behavior. Changing the behavior so that it just works with
the gs EPSCrop option has three implications:
1) A source code change to both dvipdfm(x)
2) A corresponding change to the (La)TeX graphics file, which must be
distributed at the same time as the source code patch(es).
3) Incompatibility with dvips in certain situations.
| dvipdfm doesn't correctly handle an eps figure whose lower-left
corner | is not at (0,0). In some cases, the resulting figure appears
in the | document, but is shifted. In other cases, it doesn't appear
at all. | Such figures are produced by lots of software, e.g. gnuplot.
this is a definitive bug in dvipdfm, solved in dvipdfmx.
The statement that "dvipdfm doesn't correctly handle an eps figure whose
lower-left corner is not at (0,0)" is not correct. This is exactly the
same issue as the Debian bug report and it's intended behavior to maintain
compatibility with dvips (not a bug). It's not a matter of dvipdfm (or
dvipdfmx, the behavior is the same) not handling the bb correctly, it's a
matter of dvipdfm(x) being presented with a different bounding box than
(La)TeX saw when the source was processed. In effect, the EPSCrop option
*changes* the bounding box to have a corner at (0,0).
I don't know why you say it's "solved" in dvipdfmx. Both dvipdfm and
dvipdfmx have the same behavior on files converted by an external program.
If the behavior appears different on a particular installation, it's
because the dvipdfmx config file isn't using the EPSCrop option.
I agree with Akira that many of these problems can be avoided by
converting the EPS file to PDF *first* and not trying to do it on the fly.
That way you are working with the coordinates in the PDF file and not the
coordinates in the EPS file. The on-the-fly conversion was largely
intended for compatability with old DVI files. New work should not be
done this way. This is largely a user education issue. I probably should
write a FAQ explaining why the problem exists and what a "good" work-flow
should be.
Mark
______________________________________________________________________
Mark A. Wicks mwicks@kettering.edu
Professor and Head
ECE Department, Kettering University Voice: (810) 762-7992
1700 West Third Ave, Flint, MI 48504-4898 Fax: (810) 762-9830
Reply to: