The files fts_15_1508.pdf and fts_15_1510.pdf are rendered by Ghostscript 8.71 and head (r11532) missing internal line(s) in the graphic when compared to Adobe Acrobat 9.3.3.
Ghostscript interprets the following 0.3 g 0.3 G 10 w /G3 gs % <</G3 <</CA 0.5>> >> 70 100 430 150 re 70 100 m 85 40 485 40 500 100 c 70 250 m 85 300 485 300 500 250 c B as 0.3 g 0.3 G 10 w /G3 gs % <</G3 <</CA 0.5>> >> 70 100 430 150 re 70 100 m 85 40 485 40 500 100 c 70 250 m 85 300 485 300 500 250 c f 70 100 430 150 re 70 100 m 85 40 485 40 500 100 c 70 250 m 85 300 485 300 500 250 c s but Acrobat blends the stroke with the white background instead of the filled background.
Modifying the file to only perform the stroke (changing the B* to S) results in the stroke path looking OK, so does this mean that the stroke is being treated (by Adobe) as an isolated operation, then blended with the fill? Assigning to Michael to investigate what we need to do to get this right.
Created attachment 6528 [details] stroke_only.png results with 'S' instead of 'B*' as the operator.
I noticed that we do not do the same interaction of strokes and fills as AR. I have a suspicion that we need to be doing a knockout during these strokes. I will dig further into this.
OK. So Section 7.5.1 of the PDF spec is pretty clear about this. "Portions of an object are not composited with one another, even if they are described in a way that would seem to cause overlaps (such as a self-intersecting path, combined fill and stroke of a path, or a shading pattern containing an overlap or fold-over)." So with the B operation we need to make sure not to let the stroke and the fill interact. One way to achieve this is to push a non-isolated knockout group when we encounter a B operation. We then should do the fill operation followed by the stroke operation, then we should pop the group. This will need to be done in the PDF interpreter. In fact, if we have a self-intersecting path and a stroke operation we really should be pushing a non-isolated knockout group to ensure that the self-intersections do not interact.
Assigning to Alex since changes should all be in the PDF interpreter. Alex, please feel free to ask me any questions or to give me a patch to test.
Does /Knockout work at all? Changing /B as following doesn't help. /B { OFFlevels length 0 eq { mark /Isolated false /Knockout true .dicttomark gsave strokepath pathbbox grestore 2 index add exch 3 index add exch .begintransparencygroup gsave setfillstate fill grestore setstrokestate .swapcolors stroke .swapcolors .endtransparencygroup } { newpath } ifelse } bdef
Created attachment 6786 [details] patch A patch which I believe fixes the issue. I need to do a bit more testing before committing.
Created attachment 6790 [details] patch2.diff A patch that fixes some of the issues related to this (the cited problem is fixed anyway). Going to PDf write there are some issues. Also there is a minor transparency change in a couple files that I need to investigate and looking over bmpcmp this fixes some but not all the transparency issues with \B \B*. The patch is a step in the right direction however. I will make additional progress on this in the next couple days.
Created attachment 6791 [details] patch3.diff The correct patch. Previous one was missing a file. Sorry about that....
Created attachment 6917 [details] 05_Testbild_Illustrator.pdf This file gets an error with 'patch3' due to the redefinition of 'B' and 'B*' in clist mode it is a cropping_stack not empty error. If not in clist mode, it gets /rangecheck in --.discardtransparencygroup--
Indeed. Thank you for the file. I did not get any errors in our regression testing for the patch.
Created attachment 6918 [details] 04_stroke.pdf With patch3, this file has the upper 'pink' line that goes from lower-left towards upper right showing too light. It is supposed to be the same color as the line parallel to it below it.
Created attachment 6925 [details] 05_Testbild_1.pdf A much smaller test file that still shows the problem -- Error: /rangecheck in --.discardtransparencygroup--
Created attachment 6927 [details] patch3a.diff This change for pdf_ops.pdf handles the case of a an empty path or nocurrentpoint. If the path only consists of a point (as in the 05 test case: 173.064941 340.31543 m B ) then 'strokepath' returns an empty path and 'pathbbox' will get 'nocurrentpoint' error. This change wraps both the strokepath and pathbbox in a stopped context so even a naked 'B' will not error out. Note that this patch does NOT fix the '04_Stroke.pdf' problem.
OK. Thanks Ray. I am working on the pink line issue. It does appear that the alpha is getting applied twice, with the patch and we are OK without the patch.
Looking at the file I see that it has a /ca 0.5 /CA 0.25 setting going on. I had previously verified that AR does NOT handle this correctly. It only uses the /ca command and ignores the /CA command. This was verified with a test file in Bug 689518. I will check that this is the issue in this file.
OK. So the line that has this issue is drawn using 200 150 m 400 300 l B Which means that there is a fill and stroke for the line. The fill should not be done and we should just be doing the stroke with 0.25. Digging further to find out who or how the 0.5 fill opacity and 0.25 stroke opacity are both happening for this case.
I set '#define RAW_DUMP 1' in base/gxblend.h and looked at the alpha channel and I see the value for the upper (extra light) pink line of 6% (0x10) values. For a stroke with CA == 0.25, I'd expect 0x40 which _is_ what I see for the stroke drawn with: 250 100 m 450 250 l S Note 'B' is fill and stroke and the transparency handling is described on p. 569 (PDF 1.7 Reference Manual): For transparency compositing purposes, the combined fill and stroke are treated as a single graphics object, as if they were enclosed in a transparency group. This implicit group is established and used as follows: a non-isolated knockout group is established. Within the group, the fill and stroke are performed with their respective prevailing alpha constants and the prevailing blend mode. The group results are then composited with the backdrop, using an alpha value of 1.0 and the Normal blend mode. The purpose of these rules is to avoid having a non-opaque stroke composite with the result of the fill in the region of overlap, which would produce a double border effect that is usually undesirable. We aren't getting the 'double border' effect with the patched code (the way 9.00 did), but an alpha of 0.0625 is clearly wrong. Maybe we are missing the step "th their respective prevailing alpha constants and the prevailing blend mode. The group results are then composited with the backdrop, using an alpha value of 1.0" and instead compositing with the most recent alpha value (0.25 that was used for the stroke).
Created attachment 6928 [details] 04a_Stroke.pdf This one shows that changing the second 'B' operation to actually be a path with an interior shows that the problem is a carryover from the first 'f' that causes the second 'B' area to be extra light. Note this file is already inflated so that the operators can be changed.
Created attachment 6929 [details] patch3b.diff This seems to correct the problems with the '04' class of files. Needs further testing.
After running the regression and bmpcmp, it looks like there are two things that need to be investigated on this. The softmask graphic state is getting applied twice I suspect. Likely we need to do a graphic state push clear the soft mask and then do a pop of the graphic state around the transparency group push and pop. Also, there is a problem with pdfwrite with this solution. I recall that we (Ray and I) talked about using the "is pdf write" kludge in pdf_ops.ps to avoid the extra transparency group push if we are going out to pdfwrite. I will look into fixing both of these tomorrow (Monday).
Fixed with rev 11914