Bug 691228

Checked out "SVN PRE-RELEASE 8.72" ('gs -v' output) via SVN (Revision 10741).

Same applies to this version: If -dGraphicsAlphaBits=2 or
-dGraphicsAlphaBits=4 is set and the bit depth of the device in question is higher than 1, the output is garbled:

http://kaiser-edv.de/tmp/i1jHSu/gs-872.png

With a bit depth of 1 or -dGraphicsAlphaBits=1 everything looks like expected:

http://kaiser-edv.de/tmp/i1jHSu/gs-872-mono.png
http://kaiser-edv.de/tmp/i1jHSu/gs-872-GraphicsAlphaBits_is_1.png

Tested on a Mac with MacOS X 10.5.8 and a linux box with Debian 4.0.

Created attachment 6148 [details]
original_simplified.pdf

Somewhat simplified version of original file.

I've verified that the problem does not happen with 8.64 but does with head (r11014).

Looks like r10385 is responsible for the regression:

r10385 | robin | 2009-11-25 16:47:35 -0800 (Wed, 25 Nov 2009) | 14 lines

Fix for bug 688655: stroking of wide curves with high curvature would
previously have left strange effects under the curve, and had nasty
flattening artifacts on the outside of joins.

(In reply to comment #3)
> Looks like r10385 is responsible for the regression:
> 
> r10385 | robin | 2009-11-25 16:47:35 -0800 (Wed, 25 Nov 2009) | 14 lines
> 
> Fix for bug 688655: stroking of wide curves with high curvature would
> previously have left strange effects under the curve, and had nasty
> flattening artifacts on the outside of joins.

Never mind, r10385 changed the output but it's not correct with r10384; searching for the applicable rev now.

This behaviour of this file has changed several times in recent Ghostscript history:

.
.
.
r10319 - correct
r10320 - wrong
.
.
.
r10350 - wrong
r10351 - error during conversion
.
.
.
r10376 - error during conversion
r10377 - wrong but differently than r10320
r10378 - wrong but differently than r10378
.
.
.

Luckily (or perhaps unlickily for him) all the applicable changes have been Robin's.

Marcos, thanks for your investigations. But what does this mean? Do you at Artifex agree that the current rendering behaviour is wrong and should be fixed?

I'm currently evaluating some PDF to TIFF renderers (PDF capable RIPs, Adobe's PDF Print Engine, Acrobat, Photoshop and the like). All except GS 8.71/8.72 do it right (but do have other issues with performance, max. bytemap dimensions, accessibility in the current workflow, etc.)

Unfortunately I cannot use older GS versions that do not show this specific rendering (mis)behaviour due to GS failing in interpreting the PDF or other rendering errors that with other page elements...

(In reply to comment #6)
> Marcos, thanks for your investigations. But what does this mean? Do you at
> Artifex agree that the current rendering behaviour is wrong and should be
> fixed?

I agree the current behaviour is wrong.  My analysis isolated the area of code that caused the problem and which engineer was responsible for the change, who has now been assigned the bug and will look at it in due course.  

Note that bugs from customers have priority over non-customers so it might be a while before this is fixed.  If you are interested in licensing Ghostscript for commercial use contact sales@artifex.com, potential customers have priority over non-customers.

$ svn diff gs/base/gxstroke.c
Index: gs/base/gxstroke.c
===================================================================
--- gs/base/gxstroke.c  (revision 11030)
+++ gs/base/gxstroke.c  (working copy)
@@ -1626,9 +1626,15 @@
         l = (double)(plp->width.x) /* x1 */ * (nplp->width.y) /* y2 */;
         r = (double)(nplp->width.x) /* x2 */ * (plp->width.y) /* y1 */;

-        if ((l == r) && (join == gs_join_round))
-            return add_pie_cap(ppath, &plp->e);
-        else if ((l > r) ^ reflected) {
+        if ((l == r) && (join == gs_join_round)) {
+            /* Do a cap, and leave the point on the same side as it was
+             * originally. This is required for paths that come to a stop
+             * and then reverse themselves, but may produce more complexity
+             * than we'd really like at the ends of smooth beziers. */
+            code = add_pie_cap(ppath, &plp->e);
+            if (code >= 0)
+                code = gx_path_add_line(ppath, plp->e.co.x, plp->e.co.y);
+        } else if ((l > r) ^ reflected) {
             /* CCW rotation. Join in the forward path. "Underjoin" in the
              * reverse path. */
             /* RJW: Ideally we should include the "|| flags" clause in

This seems to solve the problem in local testing. Running a localcluster test now.

Thanks, Robin. Your patch seems to fix it. I'm going to test a few hundred PDFs right now and let our image matching algorithm compare the GS results with reference images created before.

Fix committed as revision 11031.

Mr Kaiser, I'll wait to close the bug until I hear the results of your test run. Many thanks.

> Fix committed as revision 11031.

Tests done. Perfect rendering behaviour now! The results of a few hundred PDFs (somewhat problematic production data from an agency taking out an awful lot of ads every month) do not differ from any other prepress-grade PDF renderer I had access to :-)

Many thanks for the fast fix!

(In reply to comment #11)
> Tests done. Perfect rendering behaviour now! The results of a few hundred PDFs
> (somewhat problematic production data from an agency taking out an awful lot of
> ads every month) do not differ from any other prepress-grade PDF renderer I had
> access to :-)
> 
> Many thanks for the fast fix!

You're welcome. Many thanks for the additional testing.

The fix for this bug (commit cbcc4ac3c4d74ef2ca915c13c6d35a8a930ae4ff) turns out to be the change that introduced some trouble in Lilypond:
http://code.google.com/p/lilypond/issues/detail?id=2328

A white triangle appears inside lines with rounded ends when rendering to pngalpha.

I have opened bug 692862 to discuss the new issue.