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

[Hartmut Henkel]

On Sat, 23 Jun 2007, Mark A. Wicks wrote:
> On Fri, 22 Jun 2007, Frank Küster wrote:
>> namely that an image which was very large (multiples of a0) wasn't
>> included properly.  Back then, we decided to use a suggestion which
>> Heiko Oberdiek made, namely "-dEPSCrop".  However, this introduced a
>> new problem, described in
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428014:
>>
>> ,----
>> | 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.
>> `----

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

(anybody tried?)

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

well, if you look 1. at dvipdfm, it e. g. changes an incoming
%%BoundingBox: -1 -1 151 151 from an eps file created by MPost to
/BBox[0 0 2384 3370]. And nothing is shifted inside the /XObject stream.
Example attached. Anything negative in the embedded image might be
cropped by the viewer application. People do have problems with this.

Now please look 2. at dvipdfmx. It properly takes the %%BoundingBox: -1
-1 151 151 and emits it correctly into the PDF file as /BBox[-1 -1 151
151]. Nice.

Now look 3. at dvips. It properly puts the incoming %%BoundingBox: -1 -1
151 151 into the ps file as -1 @llx -1 @lly 151 @urx 151 @ury. Correct.

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

Seems in its current version 0.13.2 it doesn't any more, as you see. But
maybe it's just my setup here.

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

seems currently dvipdfm is incompatible to dvips, as it crops negative
stuff off, at least here.

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

please see the examples above. Dvipdfmx produces an embedded PDF image
whose negative parts are not cropped as in dvipdfm. The problematic
effect with xx-dvipdfm.pdf can be seen e. g. with xpdf when continuously
zooming in and out.

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

well, i thought this non-negative /BBox problem in dvipdfm is the cause
of the evil discussed, maybe i have misunderstood something, or my
installation is different, then sorry.

BTW, i'm no fan of having an incredibly large BBox with 50000 or so
numbers in some PDF file. The size of the original PDF image is well
known, but afaics it gets replaced by a fake in the embedding process,
which in fact is information loss: It annihilates the purpose of the
/BBox for /XObject. And there is the -sDEVICE=bbox mode in gs that would
tell the right bounding box. If you ever want to extract some embedded
graphics from a PDF file created by dvipdfm(x), you would have to deal
with this grossly oversized BBox, which has nothing to do with the
original, and recover a reasonable value by some (auto-)cropping. IMHO
it would be much nicer if the original BBox from the embedded eps/pdf
would go into the PDF file unchanged. But i see that there is no easy
solution with gs other than having two gs runs in sequence. I actually
had misunderstood the EPSCrop gs flag (i'm sorry, should have checked),
as i thought it would work also in pdfwrite mode, so to produce some
proper kind of "embedded" PDF, but it doesn't. Against having two gs
runs seems to be currently that the quoting mechanism in dvipdfmx.conf
does allow only single lines and no shell scripts; else maybe one could
cook up a real BBox manufacturing in the 1st gs run and tell these
numbers to gs for the 2nd run as parameters for conversion into pdf.

Regards, Hartmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x-dvipdfm.tgz
Type: application/x-gtar
Size: 29427 bytes
Desc: x-dvipdfm.tgz
Url : http://tug.org/pipermail/tex-live/attachments/20070624/ff70104a/attachment-0001.gtar