On 6/23/07, Mark A. Wicks <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Head of St. Margarets Bay, Nova Scotia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
