Created attachment 7600 [details] ta.pdf.gz This problem shifts with resolution and band height, but I've managed to reduce the file to show the problem with a minimal number of objects and low resolution (96 dpi). The command line is: gswin32c -r96 -sDEVICE=png16m -o ta.png ta.pdf The "screen snapshot" image is mostly too light (the top part is OK). This appears to be related to the painting that immediately precedes the image being drawn, which is probably leaving the opacity set at less than 1.0 (I see 0.440002 mentioned in the -Zv output). Note the attachment is a gzipped UNCOMPRESSED pdf that is useful for editing.
OK. So after the transparency group into which the bottom part of the image is going into is created during clist playback, playback is obtaining a PDF14_SET_BLEND_PARAMS compositor action where the opacity has been changed to 0.44000199. Playback is just doing what it was told to do. Question is why is this getting put into the clist for this band? Working now on tracking that down.
Digging further on the clist writing side I am starting to track things down. There is a gs_begin_transparency group that occurs. In pdf14_clist_create_compositor we find ourselves at line 6400 where we do a call to update the parameters before we start the group. You can catch this nicely by putting a break point at line 6555 in pdf14_clist_update_params, where we wait for the detection of a change in opacity. You will see the opacity set to 0.44000199. The value is stored in the parameters in c_pdf14trans_write line 5025 (another good breakpoint spot). Now the bounding box on this group is computed in gxclimag.c line 963 where we do a call to get_cropping. The computation actually occurs in c_pdf14trans_get_cropping around line 7218. We end up with a bounding box that is x=1599 y=293 to x=1948 y=611. Now if you compare that to our image that is not getting correctly drawn, you will note that we intersect into the y range with this group, but not with the x range. We end up doing the push of the blend parameters at this point across the same bands as the group which is bands 3 through 7. So this is why we are setting the alpha value in the group. The question for me is now, how is it that the top part of the image (likely in band 6) is escaping this opacity setting of 0.44 while band 7 is getting hit with it (both are in the Y range of the blend parameters). There is likely another setting of the blend parameters that is not making it to band 7 (a conjecture at this time).
Verified that there is another transparency group push that occurs later with a range of bands 3 to 6. Bounding box is x = 1678 y = 380 x =1881 y =567. opacity is 1 for this group. Hence a PDF14_SET_BLEND_PARAMS occurs for those bands. Band 7 is the odd one out here, still set to 0.44 opacity.
One last comment before bed. I do see that in pdf14_clist_begin_typed_image at line 6790 we end up doing the PDF14_SET_BLEND_PARAMS with opacity of 1 etc to all bands. But unfortunately, it does not detect a change in the opacity from what it last wrote (which happened to be 1 -- but in a different set of bands) so it does not do the writing out of that particular value and so band 7 remains at 0.44. Herein lies the problem. Lets talk about this tomorrow Ray.
Fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=096e21027a7ff99cf0e3d0d1e24dac29b2d69f12