[tex-live] Inclusion of large eps files with dvipdfm

[Mark A. Wicks]

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 at 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