I ran across a problem when using GPL GS 8.71 from MacPorts (<http://trac.macports.org/browser/trunk/dports/print/ghostscript>) on Intel Macs with MacOS X 10.5.8 and 10.6.3. When trying to render a PDF file with -dGraphicsAlphaBits=2 or -dGraphicsAlphaBits=4 I get partial rendering errors (punched out effects inside the black outline) http://kaiser-edv.de/tmp/i1jHSu/GraphicsAlphaBits.png But it should look like this: http://kaiser-edv.de/tmp/i1jHSu/no_GraphicsAlphaBits.png (verified with Acrobat, other PDF renderers and GS 8.70). The following image highlights the differing areas: http://kaiser-edv.de/tmp/i1jHSu/noticeable_Difference.png The rendering error affects only some devices. I tried the following: - pngalpha - tiff32nc - tiffgray - bmp32b - psgray - psrgb I tried others (all of them limited to a 1 bit depth of the resulting bitmap?) and the result looks like expected, so NO rendering erros occured with these devices: - pngmono - tiffg4 - bmpmono - psmono I don't think that I'm affected by the limitations of the -dGraphicsAlphaBits switch outlined in eg. <http://www.ghostscript.com/doc/current/Use.htm> since the rendering errors are so significant and I can't reproduce the behaviour with 8.70 (tried different installations on both MacOS X and Linux): Note that because of the way antialiasing blends the edges of shapes into the background when they are drawn some files that rely on joining separate filled polygons together to cover an area may not render as expected with GraphicsAlphaBits at 2 or 4. If you encounter strange lines within solid areas, try rendering that file again with -dGraphicsAlphaBits=1. Steps to reproduce: Download http://kaiser-edv.de/tmp/i1jHSu/original.pdf and try to render the PDF with a device with a bit depth > 1: gs -dBATCH -dNOPAUSE -r100 -sDEVICE= tiff32nc -dTextAlphaBits=2 -dGraphicsAlphaBits=2
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.