Bug#428014: [tex-live] Inclusion of large eps files with dvipdfm
On 6/23/07, Mark A. Wicks <mwicks@kettering.edu> wrote:
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.
Such a FAQ is badly needed, but there are some questions that users
don't ask due to mis-understandings or lack of knowledge, so maybe
a Rarely Asked Questions (that should be asked more often) or RAQ
is more appropriate.
It is a bit surprising how many people cling to EPS workflows. In my
experience, many problems with figures are due to files that have .eps
extensions but don't meet the definition of EPS. It is hard for the typical
user to tell the difference, but users need to understand that even
dubious .eps files make useful PDF files.
RAQ 1) Why does converting figures in .eps files to PDF often work,
e.g., with dvipdfm[x] when using the figures directly fails?
A1. Not all .eps files meet the definition of EPS, even if the files can
be viewed/printed. With PDF format, the view/print test is much more
likely to ensure that a figure can be placed in a tex document without
problems.
A2. For compatibility with dvips, there are some limits on the BoundingBox
entries in valid EPS files that can be used with dvipfm[x] -- the entries
should be nonegative. If EPScrop is used, they should not exceed the
values DEVICEWIDTHPOINTS and DEVICEHEIGHTPOINTS in the config file.
--
George N. White III <aa056@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
Reply to: