Bug 700306 - epstool no longer sets boundary box correctly with Ghostscript 9.26
Summary: epstool no longer sets boundary box correctly with Ghostscript 9.26
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Text (show other bugs)
Version: unspecified
Hardware: PC Linux
: P4 normal
Assignee: Robin Watts
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-02 10:50 UTC by Andrew
Modified: 2019-02-01 14:39 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
eps input file (110.91 KB, image/x-eps)
2018-12-02 10:54 UTC, Andrew
Details
eps output file (110.97 KB, image/x-eps)
2018-12-02 10:54 UTC, Andrew
Details
PostScript file that fails BB calculation (26.27 KB, application/postscript)
2018-12-19 17:59 UTC, Paul Wessel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew 2018-12-02 10:50:10 UTC

    
Comment 1 Andrew 2018-12-02 10:54:21 UTC
Created attachment 16445 [details]
eps input file
Comment 2 Andrew 2018-12-02 10:54:48 UTC
Created attachment 16446 [details]
eps output file
Comment 3 Andrew 2018-12-02 10:58:53 UTC
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
Comment 4 Ken Sharp 2018-12-02 11:02:49 UTC
(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.
Comment 6 Andrew 2018-12-02 13:59:12 UTC
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
Comment 7 Ken Sharp 2018-12-02 14:09:52 UTC
(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.
Comment 8 Andrew 2018-12-02 14:57:27 UTC
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).
Comment 9 Andrew 2018-12-08 10:42:58 UTC
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.
Comment 10 Paul Wessel 2018-12-19 17:57:41 UTC
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.
Comment 11 Paul Wessel 2018-12-19 17:59:15 UTC
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.
Comment 12 Remko Scharroo 2018-12-20 08:55:14 UTC
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.
Comment 13 Robin Watts 2019-01-31 19:36:13 UTC
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.
Comment 14 Paul Wessel 2019-02-01 14:39:31 UTC
Thanks for finding the problem; looking forward to 9.27!