Created attachment 16445 [details] eps input file
Created attachment 16446 [details] eps output file
epstool --copy --bbox XM8072.eps XM8073.eps Boundary box much too large in output file XM8073.eps Ghostscript 9.26 epstool 3.08 Linux Mint 19 64-bit PC
(In reply to Andrew from comment #3) > epstool --copy --bbox XM8072.eps XM8073.eps > > Boundary box much too large in output file XM8073.eps We don't supply epstool, as far as I'm aware, I certainly can't find any mention of it anywhere in our source or distribution tree. You will have to supply us with something we can use to reproduce the problem with Ghostscript. That means a Ghostscript command line.
Ghostscript is listed as a dependency of epstool. I believe that epstool uses Ghostscript to create a temporary image from which the bounding box is determined. Problem occurred after Ghostscript upgrade from 9.22->0.26. Epstool was not upgraded. http://www.ghostgum.com.au/software/epstool.htm
(In reply to Andrew from comment #6) > Ghostscript is listed as a dependency of epstool. And ? > I believe that epstool uses Ghostscript to create a temporary image from > which the bounding box is determined. Problem occurred after Ghostscript > upgrade from 9.22->0.26. Epstool was not upgraded. > > http://www.ghostgum.com.au/software/epstool.htm We cannot work starting from other pepole's software. We need a Ghostscript command line. If you cannot provide that then I can only suggest that you contact the author of the software which uses Ghostscript and ask them to investigate, or at least provide a command line which we can use to debug the problem. If you cannot find some way to provide us with a Ghostscript command line then I will be forced to close the bug since we will not be able to investigate the problem.
I'm an end user so am not familiar with inner workings of epstool. I have forwarded a link to this bug report to the maintainer of epstool. Only other dependency is libc6 (which I assume to be the C run-time library).
The author of epstool (Russell Lang) will, according to his website, take some time to respond. Please leave this open if possible. FYI: I compared the eps files to see the bounding box specifications. These are approximately correct for the input file: %%BoundingBox: 49 647 181 721 For the output file I see: %%BoundingBox: -2411 647 202 721 The -2411 figure is wrong, but the other values are very likely to be correct.
Here is a second example of boundingbox failure using gs directly. The file map.ps is a minimalist PS file that draws a near rectangular box only. It does this after translating the origin about ~(40,40) inches on a very large paper size and plotting a box that is about 65 cm wide. Running gs for bounding box gives the correct answer: gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox map.ps %%BoundingBox: 2879 2878 4724 3974 %%HiResBoundingBox: 2879.171912 2878.991912 4723.242606 3973.841879 However, if you comment line 26 and uncomment 25 for exactly 40 inches (the one that passes uses 39.9991666667,39.9991666667, then the boundingbox becomes gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox map.ps %%BoundingBox: 589 2879 4724 3974 %%HiResBoundingBox: 589.805982 2879.063912 4723.307856 3973.895879 The map box is approximately 65 cm which agrees with the first output but the second is way off. There is nothing magical about 40 inches. The original plot had annotations and gridlines and then things fall apart for origin shifts beyond ~9 inches. gs 9.25 works fine for this test but 9.26 fails. Something changed that affected the bounding box calculation.
Created attachment 16609 [details] PostScript file that fails BB calculation See lines 25 & 26. The slightly larger translate values causes bounding box calculation to fail.
The bug was introduced in version 9.26, as version 9.25 does not exhibit this behaviour. I suspect the bug was introduced in the functions make_bbox or zero_case in base/gxscanc.c.
Fixed with: commit 52cbdabc0627bbeb918ffeb5f0fe15a6922a8322 Author: Robin Watts <robin.watts@artifex.com> Date: Thu Jan 31 19:14:49 2019 +0000 Bug 700306: Fix values returned by bbox device. The "any part of a pixel" code in the new scan converter holds a "cursor" position that determines where edges intersect with the scanlines. The leftmost and rightmost positions of intersection are held in this as values of type fixed. The "null" cursor position is represented by using maximal/minimal values. Unfortunately, I used {max,min}_int_in_fixed, rather than {max,min}_fixed, which meant they weren't nearly as maximal/minimal as they ought to have been. This meant that the logic for inserting the real left/right hand edges went wrong, and we output spurious positions into the edgebuffer table. This in turn caused larger spans to be filled to the underlying device than expected, hence upsetting the bbox. For all other devices, there was no problem because overly large or small values are clipped away. Thanks for the report, and the simplified test file.
Thanks for finding the problem; looking forward to 9.27!