ghostscript's bbox driver gives wrong result

[Jaime Villate]

Ghostscript in Gutsy (and Hardy) gives wrong results for the Bounding Box for most EPS files I've tried. It used to work fine with gs-gpl in Feisty. One simple example of the failure is the following (using the example.ps file attached):
   gs -sDEVICE=bbox -dNOPAUSE -dBATCH example.ps
the result is wrong.

Reverting back to a previous version is hard, since the package changed its name in Gutsy.

Example.ps file's content:
----------------------------------------------------
%!PS-Adobe-2.0
%%Title: example.ps
%%Date: Sat Nov 3 20:58:13 WET 2007
%%BoundingBox: 52 97 267 163
%%Page: 1 1
0.8 0 0 setrgbcolor 1 setlinewidth
100 15 160 {100 exch moveto 120 0 rlineto stroke} for
0 setgray 0.3 setlinewidth newpath
140 130 3 0 360 arc gsave 0.7 0.6 0 setrgbcolor fill grestore stroke
/Times-Italic findfont 12 scalefont setfont
136 138 moveto (q) show
 55 127 moveto (V ) show currentpoint
225 127 moveto (V ) show
/Times-Roman findfont 12 scalefont setfont
(menor) show moveto (maior) show
showpage

[Jaime Villate (villate)]

Here is another PostScript file that shows better the bug. The command "gs -sDEVICE=bbox -dNOPAUSE -dBATCH example2.ps" gives an empty bounding box, which is wrong:
GPL Ghostscript SVN PRE-RELEASE 8.61 (2007-08-02)
Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
%%BoundingBox: 0 0 0 0
%%HiResBoundingBox: 0.000000 0.000000 0.000000 0.000000

The gs-gpl package in Edgy used to give the correct result.

(file example2.ps attached)

[Till Kamppeter (till-kamppeter)]

Reported bug upstream now:

http://bugs.ghostscript.com/show_bug.cgi?id=689562

[Till Kamppeter (till-kamppeter)]

Sorry, I did not see that you have already reported this upstream. Please add a link to your upstream report in such a case to avoid duplicate effort.

Original upstream bug report:

http://bugs.ghostscript.com/show_bug.cgi?id=689548

[Till Kamppeter (till-kamppeter)]

Seems that this got fixed already before my upstream report (upstream could not reproduce it). I have checked now with the final release of GPL Ghostscript 8.61 which I have packaged for Hardy yesterday and it shows correct bounding boxes with the two example files.

[Jaime Villate (villate)]

On Fri, 2007-11-23 at 11:06 +0000, Till Kamppeter wrote:
> Seems that this got fixed already before my upstream report (upstream
> could not reproduce it).
yes, before I reported it to you, they had told me upstream that it
worked fine with the latest svn version. I'm sorry I didn't tell you
that :(

> I have checked now with the final release of
> GPL Ghostscript 8.61 which I have packaged for Hardy yesterday and it
> shows correct bounding boxes with the two example files.
great. Yes I have just updated and it now works fine.
Thanks a lot; my life depends on it because I have lots of figures
in my lecture notes that use ghostscript to calculate the bbox before
they can be converted into PDF and added to
the notes (http://fisica.fe.up.pt/eic0014/fisica2.pdf).

Regards,
Jaime Villate
University of Porto, Portugal

[Jaime Villate (villate)]

I have just notice something strange. If in the test file example2.ps I remove the line that says "%!PS-Adobe-2.0",
the bug appears again: the file (see example3.ps attached) is recognized as PostScript, but the bounding box is wrong:

> ghostscript -sDEVICE=bbox -dNOPAUSE -dBATCH example3.ps

GPL Ghostscript SVN PRE-RELEASE 8.61 (2007-08-02)
Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
%%BoundingBox: 0 0 0 0
%%HiResBoundingBox: 0.000000 0.000000 0.000000 0.000000

[Jaime Villate (villate)]

One more thing. This PS file also gives an error:

%!PS
210 490 moveto 120 60 rlineto -10 10 rlineto -120 -60 rlineto closepath clip
newpath
195 495 moveto 125 65 rlineto -10 10 rlineto -125 -65 rlineto closepath fill
showpage

while this one works fine:

%!PS-Adobe
210 490 moveto 120 60 rlineto -10 10 rlineto -120 -60 rlineto closepath clip
newpath
195 495 moveto 125 65 rlineto -10 10 rlineto -125 -65 rlineto closepath fill
showpage

(The only difference is the word Adobe in the header)

[Till Kamppeter (till-kamppeter)]

Please report these two cases in new upstream bug report and post links to them here.

Note that the "%!PS-Adobe-N.M" lines mark DSC compliance of a PostScript file (preparation sections and pages separated by special comments to allow page management). If this magic string (string in the beginning of a file to identify its type) is added to a PostScript file which is not DSC compliant, it can perhaps cause misbehavior, but I do not know whether this applies to GhostScript's bounding box calculation, so report the bugs upstream anyway.

As it seems that the success of the boundary box calculation only depends on how the magic string looks like, use the correct magic string in the meantime. If you have very many PostScript or EPS files, let a script correct your magic strings.

[Jaime Villate (villate)]

This bug has reappeared in more recent versions that I have tested in i386 and AMD64:
     8.61.dfsg.1-1ubuntu3
and the one that comes with the beta release of Intrepid:
    8.63.dfsg.1-0ubuntu4

I have compiled version 8.63 from the upstream sources, and it does not have this bug.
The problem is that a lot of packages depend on ghostscript and its shared library, which
makes it painful to have to recompile everything. David Munro has discovered a hack (including
a -dSAFER option) but still, it would be nice to have a regular working version in Intrepid.

[Herbert V. Riedel (hvr)]

just in case this helps anyone debug, I noticed that the bounding box calculation is affected by the color value; if I draw lines with a white component, e.g. by '0.5 setgray' they get considered by the bounding box algorithm, whereas completely black lines don't make it...

%!PS-Adobe-2.0
%%Creator: foo
%%BoundingBox: 197 398 367 602
%%DocumentMedia: A4 595 842 0 () ()
%%EndComments
/mainfont /Courier findfont 14 scalefont def
mainfont setfont
%%EndProlog
%%Page: 1 1
0.0 setgray
250 450 moveto
(Hello, World!) show
200 400 moveto
50 100 rlineto
0 -100 rmoveto
-50 100 rlineto
3.5 setlinewidth
stroke
0.5 setgray
260 550 moveto
(Hello, World!) show
210 500 moveto
50 100 rlineto
0 -100 rmoveto
-50 100 rlineto
3.5 setlinewidth
stroke
showpage
%%Pages: 1

[Till Kamppeter (till-kamppeter)]

Can you please report this upstream (on http://bugs.ghostscript.com/)? Thanks.

[Till Kamppeter (till-kamppeter)]

This bug was caused by our patches for CJK (Chinese, Japanese, Korean) support. As the CJK issues are treated upstream now, the patches will get dropped for our Ghostscript 8.64 package. Ghostscript 8.64 will get released February 1st.

[Till Kamppeter (till-kamppeter)]

Fixed in ghostscript_8.64.dfsg.1~svn9377-0ubuntu1 in Jaunty (development snapshot of GS 8.64).

[Till Kamppeter (till-kamppeter)]

With the final release of Ghostscript 8.64 (which is now in Jaunty) also example3.ps gives the correct bbox output.