Bug 698713 - Regression: -dGraphicsAlphaBits=4 causes horizontal lines in path fill
Summary: Regression: -dGraphicsAlphaBits=4 causes horizontal lines in path fill
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Regression (show other bugs)
Version: 9.22
Hardware: Macintosh MacOS X
: P4 normal
Assignee: Robin Watts
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-31 12:16 UTC by Eric
Modified: 2017-11-02 10:58 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
The source file (170.85 KB, application/postscript)
2017-10-31 12:16 UTC, Eric
Details
The 9.21 output (43.31 KB, image/png)
2017-10-31 12:17 UTC, Eric
Details
The 9.22 output (57.25 KB, image/png)
2017-10-31 12:17 UTC, Eric
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric 2017-10-31 12:16:47 UTC
Created attachment 14429 [details]
The source file

The attached PS file produces horizontal lines in 9.22 that are not present when rasterized in 9.21. The command used is:

/opt/local/bin/gs -sOutputFile=output92X.png -sDEVICE=png48 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -q -dBATCH -dNOPAUSE -r170 -f outputPS2.ps
Comment 1 Eric 2017-10-31 12:17:11 UTC
Created attachment 14430 [details]
The 9.21 output
Comment 2 Eric 2017-10-31 12:17:30 UTC
Created attachment 14431 [details]
The 9.22 output
Comment 3 Chris Liddell (chrisl) 2017-10-31 12:33:49 UTC
Almost certainly this issue:

https://bugs.ghostscript.com/show_bug.cgi?id=698672

*** This bug has been marked as a duplicate of bug 698672 ***
Comment 4 Ken Sharp 2017-10-31 12:36:42 UTC
This appears to be yet another weird interaction of GraphicsAlphaBits and the news scan converter.

You can restore the old behaviour by setting -dSCANCONVERTERTYPE=0

For ease of use debugging on Windows, the png16m device exhibits the same behaviour, as do other devices such as tiff24nc.
Comment 5 Ken Sharp 2017-10-31 12:37:17 UTC
(In reply to Chris Liddell (chrisl) from comment #3)
> Almost certainly this issue:

I don't think so, its still exhibits with HEAD for me.....
Comment 6 Eric 2017-10-31 12:39:24 UTC
Thanks for locating the (potential) duplicate bug. Of note, the search engine cannot find the duplicate when searching for "GraphicsAlphaBits", which is why I didn't find it in my initial search.
Comment 7 Chris Liddell (chrisl) 2017-10-31 12:47:08 UTC
(In reply to Eric from comment #6)
> Thanks for locating the (potential) duplicate bug. Of note, the search
> engine cannot find the duplicate when searching for "GraphicsAlphaBits",
> which is why I didn't find it in my initial search.

Yeh, sorry, as Ken says, it still shows in the current code, so it's not the same problem - I must have mis-typed the command line when I tried it.
Comment 8 Robin Watts 2017-11-02 10:58:12 UTC
Fixed with: commit 1626f36c9b6ae68abad7818be7cfb2a95f4ecffe
Author: Robin Watts <robin.watts@artifex.com>
Date:   Thu Nov 2 17:54:57 2017 +0000

    Bug 698713: Further graphicsAlphaBits + new scan converter fix.

    Previous I ensured that when using graphicsAlphaBits, the new scan
    converter would restrict its output rectangles/traps to fit
    within y % max_fill_band pixels at a time as required.

    I forgot that the base 'y' value taken for this was not necessarily
    aligned to a max_fill_band multiple. Fixed here.

Thanks for the report.