[tex-live] Inclusion of large eps files with dvipdfm
George N. White III
gnwiii at gmail.com
Sun Jun 24 13:21:41 CEST 2007
On 6/23/07, Mark A. Wicks <mwicks at 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
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 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the tex-live