[tex-k] epstopdf confused at eps files with two bounding box lines

Heiko Oberdiek heiko.oberdiek at googlemail.com
Wed Apr 18 23:50:37 CEST 2018


On 2018-04-18 18:41, Tao Zhao wrote:
> Hi,
> It seems that epstopdf will be confused when the eps figure has two
> bounding box lines. Attached is an figure for example. epstopdf will
> pick up the first bounding box line, which is actually wrong. In
> contrast, gv can detect and show the correct size (bbox) of the
> figure.

1. Illegal operator setpagedevice

The attached PostScript file contains a setup section that sets the
media size explicitly via setpagedevice:

     %%Feature: *Resolution 600dpi
     TeXDict begin
     %%BeginPaperSize: Letter
     /setpagedevice where
     { pop << /PageSize [612 792] >> setpagedevice }
     { /letter where { pop letter } if }

The operator is an illegal operator in Encapsulated PostScript,

Therefore, the file Pythagoras.eps is *not* an EPS file
and tools like `epstopdf' or `ps2pdf -dEPSCrop` are allowed
to fail.

Fix: dvips should be used with option -E to improve the
EPS compatibility of the generated file.

Workaround: Remove the lines between %%BeginPaperSize
and %%EndPaperSize.

2a) Different types of bounding boxes

The file starts with:

     %%BoundingBox: 234 320 377 471
     %%HiResBoundingBox: 234.600623 320.5 376.399377 470.5

The first bounding box uses is "rounded" to integer values
(unit is bp). Rounding means "floor" for the first two
smaller values and "ceil" for the latter two larger

The high resolution bounding box uses float numbers.

The program "epstopdf" uses %%BoundingBox by default.
Option `--hires` switches to %%HiResBoundingBox.

The bounding box by ghostscript

     gs -sDEVICE=bbox -q -dBATCH -dNOPAUSE Pythagoras.eps

reports slightly different values:

     %%BoundingBox: 234 326 375 471
     %%HiResBoundingBox: 234.593149 326.159990 374.543989 470.537986

2b) Inner bounding boxes

The "second" pair of bounding boxes:

     %%BoundingBox: -1 -25 142 126
     %%HiResBoundingBox: -0.25 -24.7839375 141.548755 125.216063

belong to a different, embedded PostScript file:

     %%BeginDocument: Pythagoras_0.eps
     %!PS-Adobe-3.0 EPSF-3.0
     %%BoundingBox: -1 -25 142 126
     %%HiResBoundingBox: -0.25 -24.7839375 141.548755 125.216063

Such inner bounding boxes are not considered by "epstopdf".

3. Alternative approach via pdfcrop

If the PostScript file makes too much trouble, then convert
it to PDF and run `pdfcrop`. This tool uses ghostscript for
the bounding box and generates a trimmed PDF file.

> More details: This figure is generated by Asymptote, and the first
> bounding box line seems to come from calling dvips in the process. So
> I don't think there is an easy way to get rid of it from Asymptote.
> Besides, the Asymptote guys do not recommend epstopdf, and seems like
> they don't think this is an issue they should address.

Since they are generating invalid EPS files, see above,
they *should* address it.

> Why do I need to use epstopdf? Because I'm working on publishing to a
> journal which accepts eps figures but not pdf figures. Currently I
> walkaround the issue by converting .asy to .pdf then to .eps.

If .asy is directly converted to .pdf and the step to .eps
does not make harm (like converting fonts to bitmaps, ...),
then it is a good way to generate EPS files. Example for the latter
step is (pdftops -eps).

> But I do
> hope the straightforward workflow .asy to .eps will work with
> epstopdf.

"epstopdf" does *not* generate EPS.

> So, can we make epstopdf smarter at detecting the right bounding box
> of eps figures?

* The attached EPS file does not contain a correct bounding box,
   see above.
* The program epstopdf already contains options to select
   the type of the bounding box: --hires, --exact.

Yours sincerely

More information about the tex-k mailing list