The customer reports errors with the combination of transparency and GraphicAlphaBits. I've duplicated their problem with 8.64 and head (r9743). Here is their original report: We are facing some problems when using GS for interpreting the 'pdf' file. ( pdf file is attached. 'BigBBoxTesting_1_Clipped.pdf'). We tried the png16m device ( to get RGB output) and pngalpha device ( to get RGB with transparency output). Also we tried different combinations for Graphics smoothing. We used the following command lines to generate the output. // Without Graphics smoothing. Without Transparency // NoSmoothingNoAlpha.png gswin32c -dSAFER -dBATCH -dNOPAUSE -r72 -sDEVICE=png16m -dGraphicsAlphaBits=1 - sOutputFile="NoSmoothingNoAlpha.png" "BigBBoxTesting_1_Clipped.pdf" // With Graphics smoothing. Without Transparency // WithSmoothingNoAlpha.png gswin32c -dSAFER -dBATCH -dNOPAUSE -r72 -sDEVICE=png16m -dGraphicsAlphaBits=4 - sOutputFile="WithSmoothingNoAlpha.png" "BigBBoxTesting_1_Clipped.pdf" // Without Graphics smoothing. With Transparency // NoSmoothingWithAlpha.png gswin32c -dSAFER -dBATCH -dNOPAUSE -r72 -sDEVICE=pngalpha -dGraphicsAlphaBits=1 - sOutputFile="NoSmoothingWithAlpha.png" "BigBBoxTesting_1_Clipped.pdf" // With Graphics smoothing. With Transparency // WithSmoothingWithAlpha.png gswin32c -dSAFER -dBATCH -dNOPAUSE -r72 -sDEVICE=pngalpha -dGraphicsAlphaBits=4 - sOutputFile="WithSmoothingWithAlpha.png" "BigBBoxTesting_1_Clipped.pdf" // Without Graphics smoothing. With Transparency. Resoultuin 300 // NoSmoothingWithAlpha_Big.png gswin32c -dSAFER -dBATCH -dNOPAUSE -r300 -sDEVICE=pngalpha -dGraphicsAlphaBits=1 - sOutputFile="NoSmoothingWithAlpha_Big.png" "BigBBoxTesting_1_Clipped.pdf" Following errors were observed. 1) Image "NoSmoothingNoAlpha.png" was OK. 2) Image "NoSmoothingWithAlpha.png" was OK. 3) Image "WithSmoothingNoAlpha.png" white color of the center region box converted to black. 4) Image "WithSmoothingwithAlpha.png" white color of the center rectangular area converted to black., also there was no transparency present in the center rectangular area. 5) In the last case "NoSmoothingWithAlpha_Big.png" we observed that by just changing resolution from 72 dpi ( as in case of "NoSmoothingWithAlpha.png") to 300 dpi we lost the transparency in the image.
Created attachment 5023 [details] BigBBoxTesting_1_Clipped.pdf
Alex, please reassign this to Michael if it is another instance of smoothing not working correctly with the pdf14 (transparency) compositor.
Created attachment 5025 [details] i4.pdf - decompressed sample file This problem seems to be a bad interaction between pngalpha device and pattern rendering. Occasionally, I've got unexpected results even with -dGraphicsAlphaBits=1 The new sample file is a decompressed and modified version of the original file. If the rectangle is filled (see the file) the bug disappears.
This PS program generates filled boxes with the following command line: gswin32c -dGraphicsAlphaBits=4 pat.ps So, the bug is in the interaction between smoothing and pattern rendering. %! << /PatternType 1 % Tiling pattern /PaintType 1 % Colored /TilingType 1 /BBox [0 0 60 60] /XStep 60 /YStep 60 /box { 0 0 12 12 rectstroke } bind /PaintProc { begin 0.3 setgray 15 15 translate box 30 30 translate box 0.7 setgray -30 0 translate box 30 -30 translate box end } bind >> matrix makepattern setpattern 120 120 184 120 4 copy rectfill 0 setgray rectstroke showpage
Valgrind reports just 1 relevant error for valgrind gs -dGraphicsAlphaBits=4 -sDEVICE=bmp16m -o /dev/null pat.ps This software comes with NO WARRANTY: see the file PUBLIC for details. Conditional jump or move depends on uninitialised value(s) at 0x8A7241: gx_default_copy_alpha (gdevdbit.c:281) by 0x8A5C28: abuf_flush_block (gdevabuf.c:218) by 0x8A5C7A: abuf_flush (gdevabuf.c:235) by 0x8A5CEB: mem_abuf_close (gdevabuf.c:246) by 0x842C99: alpha_buffer_release (gspaint.c:236) by 0x84348A: gs_stroke (gspaint.c:456) by 0x41A382: gs_rectstroke (gsdps1.c:298) by 0x41BB19: zrectstroke (zdps1.c:333) by 0x4BD42F: call_operator (interp.c:111) by 0x4BFD7F: interp (interp.c:1162) by 0x4BDAE3: gs_call_interp (interp.c:496) by 0x4BD91C: gs_interpret (interp.c:454) It should be relatively easy to trace this back to the origin of the error.
Tried comment #4 ps code with r9980 on Mac OS X. Reproduced filled rectangle with command line: 'bin/gs -dGraphicsAlphaBits=4 -sDEVICE=x11 pat.ps'
Looked a bit at this. It appears that there is a problem having gx_default_copy_alpha for the copy_alpha operation with the pattern accumulator.
I can reproduce this bug with Ubuntu 9.10 and ghostscript 8.70. The update destroy my production redering system and I had to downgrade to ubuntu 8.04 with ghostscript version 8.63 to get the system back to a production state. For me this Bug is realy important because all dependencys with imagemagick and pdf/eps transparency are broken too. This also effects a lot of other programs that using imagemagick. For me a usefull pdf conversion is no longer given. Funny is that the Bug seems to effect not all types of pdf. I have a conversion from a eps to a PDF and than to a transparent PNG. In our environment I can reproduce that some of the PDF converted correct if the desitnation size is different. The basefiles are all standardised in our system thats why I am not thinking its a problem of different types of EPS or PDF files. I'll hope this helps. If you need some more informations I will provide all I can find.
Created attachment 6258 [details] simplified.pdf A reduced example file that also has the issue. Basically a pattern fill of a small rectangle. The pattern itself consists of only a green stroke of a rectangle.
(In reply to comment #8) > I can reproduce this bug with Ubuntu 9.10 and ghostscript 8.70. The update > destroy my production redering system and I had to downgrade to ubuntu 8.04 > with ghostscript version 8.63 to get the system back to a production state. I don't know if you want to go to that amount of trouble, but since you know it is between 8.63 and 8.70 (and it used to work in 8.63), you could try git bisect'ing to give a precise revision which breaks. (after git-svn clone'ing the ghostscript repository).
For sure the 8.63 release version dount have this problem and since the 8.64 release it is broken. I tryed also some versions between 8.64 and 8.70 they all have the same bug. This is what I figured out today and get the server back to production. If I have a bit more time I'll take a deeper look to the git.
(In reply to comment #11) > For sure the 8.63 release version dount have this problem and since the 8.64 > release it is broken.... That's useful - at least some of us can have a go at a smaller set of changes.
I have made a bit of progress on this. It appears that the pattern_accum_get_bits_rectangle function is returning regions that were not drawn in, this is sort of mentioned in the comment (line 548 in gxpcmap.c). What is happening in the non-transparency device case, is that chunks of uninitialized memory regions are getting passed along to the gx_default_copy_alpha function. On windows debug, these appear as 0xcdcdcd (205 205 205) gray for an rgb device. Other systems or devices the regions may be black. I can't imagine how this ever worked in the past as mentioned by the posts above.
(In reply to comment #12) > (In reply to comment #11) > > For sure the 8.63 release version dount have this problem and since the 8.64 > > release it is broken.... Sorry I think this is mis-information - I git bisect'ed and can't find the revision. Then I tried 8.15 (http://koji.fedoraproject.org/koji/buildinfo?buildID=2800) and the problem was there with attachement 6258. Since you said you have downgraded to 8.63 - can you give this a try again? I really think this is as Michael commented in comment 13, it has never worked. This is probably the same problem as bug 690865 and bug 691181 . (and possibly other rendering bugs with the x11alpha device).
I should have a fix for this shortly but I need to do a bit of testing. It appears that simply initializing the pattern bit buffer to white, fixes the issue since we are then not accessing uninitialized data during the pattern get_bits operation when we are in the gx_default_copy_alpha operation. One thing I have observed is that using alphabits when the output device is CMYK based for this file results in wrong colors. I want to take a quick look at that issue too. It appears to me that gx_default_copy_alpha has problems with respect to this.
Fixed with rev 11211.
Created attachment 6271 [details] a possible fix to the build breakage in r11211 r11211 breaks builds, and was reverted in r11212. The problem is that alpha_buffer_bits() was added to gsutils.c which mkromfs depends on; so building mkromfs fails with unsatistied dependencies. Here is a possible fix - adding alpha_buffer_bits() to gsalpha.{h,c} instead of gsutils.{h,c}. I don't think this is the correct answer - the correct answer probably involves some re-factoring, but in any case, adding alpha_buffer_bits() to some other files than gsutils.{h,c} and gsalpha.{h,c}.
Created attachment 6272 [details] A patch that should build.... A patch that should build and work properly.
r11213 builds alright on linux.
Tried the original pdf file and also the the pat.ps in comment 4. works like a charm.
Created attachment 6385 [details] not_a_rectangle.png There are still problems here, the attached png was rendered with: ./gs -dGraphicAlphaBits=4 -sDEVICE=pngalpha -sOutputFile=foo.png test2.pdf and part of the rectangle is missing. test2.pdf is the file name for Michael's simplified.pdf file attached to this bug.
Reopening to figure out png problem.
Not sure when this was fixed, but it appears to work fine for me now with rev 12345