This bug tracks the missing image on the sample PDF file from the bug 689272. The image comes from the object 19 0, which is an image with a soft mask. If the soft mask key is removed, the image reappears.
Please get the sample file from the bug 689289, not 689272 as stated above.
reassigning to image owner.
Assigning to Michael in case it's related to 688601. I actually see two issues. There's a pale background image missing under the text at the upper left, and there are black dropouts in the letters in the lower right image that are blue in evince.
Making some progress on this one. It does not, at this point, appear to be an issue with respect to the Smask and the graphic state like the other smask issues that I have run into. In this particular case, the Smask is defined within the image object and we are creating the transparency group after we push and pop the transparency group mask, as the code was designed. Oddly though, when the image is drawn (after creating the transparency group), no rectangles are put into the pdf14 buffer. Looking into why.
The missing image is given as object 19 below with the 1-bit smask image. As I said above, the transparency code seems to be working correctly. During the push of the smask, image_render_simple uses copy portrait to copy the smask data in object 20 to the PDF14 device. Then, the pop mask occurs and a push of a transparency group occurs. The rendering of the image data of the 100Wide by 67High image data in object 19 should then occur. This image is handled as a image type 3x. It seems to contain a mask of its own which is also a 1x1 like the image in object 20. This is sent to a memory device using image_render_simple. For some reason, it never seems to do anything with the real image data, but flushes and moves on. At one point, the renderer is set up as image_render_color, but it never uses it. It seems that one it finishes up with the tiny mask associated with the image type 3x it cleans up and moves on. 19 0 obj << /Subtype /Image /Width 100 /Height 67 /ColorSpace /DeviceRGB /BitsPerComponent 8 /SMask 20 0 R /Length 17359 /Filter /FlateDecode >> stream IMAGE DATA endstream endobj 20 0 obj << /Subtype /Image /Width 1 /Height 1 /ColorSpace /DeviceGray /BitsPerComponent 1 /Decode [ 0.7 0 ] /Length 1 >> stream .endstream endobj
Still reproducible with r9781, post smask merge.
Created attachment 7522 [details] Patch for Bug689290
Bug still reproducible in Ghostscript 9.03
Taking ownership for now, I will review the patch and make further comment if required.
The patch looks good to me. I've done a cluster regression test, and it seems fine. The test shows differences with the pdfwrite device and fts_26_2604.pdf, but I'm not sure why. However the differences are indetectable visually so I'm not going to worry about them. Thanks for the patch Shelly, sorry this has taken so long to work through.