The customer reports and I've verified that the attached PDF is rendered differently in gshead (r8296) vs. Acrobat Reader (v7.0). Specifically the 2nd story on the top floor of the first image has a brick pattern superimposed on the siding in the Ghostscript output but not in the Acrobat Reader output (see screenshot.png, attached). The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -sOutputFile=test.ppm -r300 ./1_1_2.pdf
Created attachment 3477 [details] 1_1_2.pdf
Created attachment 3478 [details] screenshot.png
the screenshot is confusing because it compares different subareas of the file. Ghostscript's output looks like evince. Possibly related: $ bin/gs -sDEVICE=x11alpha -r36 1_1_2.pdf GPL Ghostscript SVN PRE-RELEASE 8.61 (2007-08-02) Copyright (C) 2007 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 Error: /unknownerror in --run-- Operand stack: --dict:6/15(L)-- 2368.8 50.0001 Works with the x11 device.
sorry, the screenshot is correct. I was confused by the three different renderings in Acrobat, Ghostscript and evince.
Interestingly, this works for me. Checking to see what's different about my sources (I'm running 8247 currently). First I'll update to head.
It didn't work after all -- I was looking at the output wrong. This is *probably* a transparency issue.
Per request I'm retesting this customer's bugs: this one still occurs with r8596.
support has requested a status update for this problem. Please add a new comment entry or send mail to Marcos.
I've not been able to track down the origin of this problem. I expect it will be some time before I have a fix.
Just a note. I "think" ghostscript output is OK with -dNOTRANSPARENCY (which is why I suspected a transparency issue).
Marcos, please verify acrobat 8 tiff output vs ghostscript. Passing to Michael.
Created attachment 5102 [details] simplified.pdf
Created attachment 5103 [details] ghostsript.png Ghostscript generated PNG file.
Created attachment 5104 [details] acrobat.png Adobe Acrobat 9 Pro generated PNG file.
Created attachment 5105 [details] more_simplified.pdf
Beginning (with -dPDFSTEP) at step 1845, there is a sequence that does a fill that (with -dNOTRANSPARENCY) erases the inner area where GS differs from Adobe. This is color 1 1 1 in colorspace CS0. This colorspace is ICCBased with an Alternate colorspace of DeviceRGB, so "1 1 1" should be white. It seems like this has no effect. Turning on -Zv, however, shows: /CS0 cs %Resolving: [16 0] 1 1 1 scn 649.114 1290.02905 153.188 -43.688 re f [v](0x194dfa0)shape.alpha = 1 [v](0x194dfa0)opacity.alpha = 0.5 [v]set_marking_params, opacity = 0.5, shape = 1, bm = 0 [v]pdf14_mark_fill_rectangle, (139, 92), 461 x 183 color = 0000000000ffffff bm 0, nc 4, overprint 0 I don't understand what's going on, but figured I'd document what I found to maybe save Michael some time.
Reproduced with r9948 on MacBook Pro 13" + OS X 10.5.7 + Xcode 3.1.2. Regarding Ray's comment #16, it seems graphic state first created with opacity=0.5. I am not sure if this counts or not. $ debugobj/gs -Zv -dNOPAUSE -DBATCH -dPDFSTEP -sDEVICE=x11 ../../b689518/more_simplified.pdf GPL Ghostscript SVN PRE-RELEASE 8.71 (2009-08-01) Copyright (C) 2009 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. << step # 1 ? 2000 %Resolving object stream: %Resolving compressed object: [5 0] << /Kids [{9 0 resolveR}] /Count 1 /Type /Pages >> Processing pages 1 through 1. Page 1 %Resolving object stream: %Resolving compressed object: [15 0] << /Type /ExtGState /ca 0.5 >> %Resolving compressed object: [16 0] [/ICCBased {12 0 resolveR}] [v](0x1335034)blend_mode = Compatible [v](0x1335034)text_knockout = true [v]gs_pdf14_device_push [v]pdf14_open: width = 134, height = 100 [v]base buf: 134 x 100, 4 channels [v]set_marking_params, opacity = 1, shape = 1, bm = 0 [v](0x1335034)shape.alpha = 1 [v](0x1335034)opacity.alpha = 0.5 [v](0x1335034)begin_transparency_group [645.338 1240.07 799.026 1295.37] Num_grp_clr_comp = 0 (no CS) Isolated = 1 Knockout = 0 [v](0x1335034)gx_begin_transparency_group [645.338 1240.07 799.026 1295.37] Num_grp_clr_comp = 0 (no CS) Isolated = 1 Knockout = 0 [v]pdf14_begin_transparency_group, I = 1, K = 0, alpha = 0.5, bm = 0 [v]pdf14_update_device_color_procs ... [v](0x1335034)shape.alpha = 1 [v](0x1335034)opacity.alpha = 0.5 [v]set_marking_params, opacity = 0.5, shape = 1, bm = 0 [v]pdf14_mark_fill_rectangle, (31, 38), 103 x 42 color = 0000000000ffffff bm 0, nc 4, overprint 0 ...
Created attachment 5368 [details] bug_689518_simple.pdf This file is as simple as it gets for this problem. There is a stroke with a black RGB value followed by a fill with a white RGB color. Both colors are defined by an ICC RGB color space and should be drawn going through a 50% alpha set from an extended graphic state. The white fill should blow away the black fill, but for some reason that is not happening. Should not take to long to figure this out.
Created attachment 5372 [details] bug_689518_Problem.pdf Analyzing the simplified file, and creating the attached new one it appears the issue is that AR is NOT following the specification. In this new file, an extended graphic state is set that sets the nonstroking alpha to 0.25, using the \ca command. The stroking alpha is set to 0.75 using the \CA command. Following this, a stroke with an RGB value of 0 1 0 is performed, which draws a green stroke. After the green stroke is drawn, a fill is performed with the same RGB value of 0 1 0. AR appears to have 0.25 alpha for both the stroke and the fill. Upon experimentation, setting of \CA appears not to have any effect with AR. For GS Stroke is drawn with 0.75 alpha Fill is drawn with 0.25 alpha But during composition during the group pop, an additional alpha of 0.25 is applied which came from a global alpha value. This global alpha value of 0.25 comes about due to the fact that the extended graphic state is set prior to the push of the transparency group. This means that the group itself should have the nonstroking alpha applied to it. Hence the extra 0.25. Specifically, we have the PDF content below: Where 8 0 sets the opacity for the stroking and nonstroking operations. 11 0 is where the transparency group is defined and where the stroke and fill occur. Note that in 7 0 which is the main contents, the extended graphic state is set for ca = 0.25 and CA = 0.75. Then the group is formed (hence the 0.25 to apply to the group) The stroke occurs (with CA = 0.75), the fill occurs with ca = 0.25. All these items get the 0.25 applied to them when the group completes. 6 0 obj <</Contents 7 0 R /CropBox[612 1224 756 1332] /MediaBox[612 1224 756 1332] /Parent 1 0 R /Resources<</ExtGState<</GS0 8 0 R>>/XObject<</Fm0 11 0 R>>>>/Rotate 0/Type/Page>> endobj 7 0 obj <</Length 47>> stream q 18 40 2556 1670 re W n q /GS0 gs /Fm0 Do Q Q endstream endobj 8 0 obj <</Type/ExtGState/ca 0.25/CA 0.75>> endobj 11 0 obj <</BBox[645.338 1245.92 799.026 1290.1] /Type/XObject/FormType 1/Group<</I true/K false/S/Transparency>> /Length 175 /Resources<</ColorSpace<</CS0 10 0 R>>>> /Subtype/Form>> stream q 1 0 0 -1 679.1649933 1284.169693 cm /CS0 CS 0 1 0 SCN 3.000 w 2.818 M 2 J 0 0 m 0 100.0 l S Q q 1 0 0 -1 679.1649933 1284.169693 cm /CS0 cs 0 1 0 scn 10 10 50 -50 re f Q endstream endobj The source of the bug for 689518 is essentially due to the fact that AR is not paying attention to the CA value. In the original file, the CA value is set to 0.5 but the ca value is not set. So, when the white fill occurs in AR it does not do it with an alpha of 0.5 but with a alpha of 1.0 which blows away all the strokes that were drawn under the fill (these are the ones that show up when the file is processed with GS). Since GS is doing the proper operation based upon the specification and AR has a serious issue, I strongly recommend that we do not attempt to match AR in this case.
Based upon the fact that AR is not following the PDF specification and GS is, this is not a bug.
Changing customer bugs that have been resolved more than a year ago to closed.