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

[Tao Zhao]

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.

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.

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. But I do
hope the straightforward workflow .asy to .eps will work with
epstopdf.

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

[1] https://sourceforge.net/p/asymptote/discussion/409349/thread/267c480e/

Regards,
Alick

[Heiko Oberdiek]

Hello,

Post by Tao Zhao
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:

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

The operator is an illegal operator in Encapsulated PostScript,
see:
https://web.archive.org/web/20170818010030/http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/postscript/pdfs/5002.EPSF_Spec.pdf

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

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

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.

Post by Tao Zhao
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.

Post by Tao Zhao
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).

Post by Tao Zhao
But I do
hope the straightforward workflow .asy to .eps will work with
epstopdf.

"epstopdf" does *not* generate EPS.

Post by Tao Zhao
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
Heiko

[Reinhard Kotucha]

[... stuff omitted ...]
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. But
I do hope the straightforward workflow .asy to .eps will work with
epstopdf.
So, can we make epstopdf smarter at detecting the right bounding box
of eps figures?

As Heiko already pointed out, epstopdf works as expected if the input
file complies with the standards.

You could try

asy -f pdf file.asy
pdftops -eps file.pdf file.eps

pdftops is part of Derek Noonburg's Xpdf distribution.

What I don't understand is why some publishers still insist on EPS.
This is quite strange. They are still living in the early nineties.

Regards,
Reinhard

[Tao Zhao]

On Wed, Apr 18, 2018 at 6:31 PM, Reinhard Kotucha

Post by Reinhard Kotucha

[... stuff omitted ...]
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. But
I do hope the straightforward workflow .asy to .eps will work with
epstopdf.
So, can we make epstopdf smarter at detecting the right bounding box
of eps figures?

As Heiko already pointed out, epstopdf works as expected if the input
file complies with the standards.

OK, I'll file a bug report to Asymptote then.

Post by Reinhard Kotucha
You could try
asy -f pdf file.asy
pdftops -eps file.pdf file.eps
pdftops is part of Derek Noonburg's Xpdf distribution.

Yeah this is actually what I am doing for walkaround.

Post by Reinhard Kotucha
What I don't understand is why some publishers still insist on EPS.
This is quite strange. They are still living in the early nineties.

I'll also try write to the publisher... They should accept pdf figures.

Regards,
Alick