The customer reports and I've verified: The attached PDF is rendered by Ghostscript with the central image missing because of transparency. I can't tell any more whether this one has anything to do with bug 688601, but it APPEARS to be that the SMask is being ignored, so maybe it's bug 689931? Maybe not... It happens with gs8.54 and gshead (r8838). The command line I used for testing: bin/gs -sDEVICE=ppmraw -sOutputFile=test.ppm ./transfu2.pdf
Created attachment 4218 [details] transfu2.pdf
Making progress on this. I have gone through the PDF itself by hand to understand what should be going on. There are 3 CMYK images each with a Smask. Now I am taking apart what ghostscript is doing using -dPDFDEBUG and various breakpoints to understand why it is not compositing the Masks and the images properly. Hopefully I will have something of substance on this very shortly.
I believe I know what is going on and it is closely related to 688601. Essentially we have a case where a softmask is getting set for the graphic state and there is no transparency group ever created. Here is a snippet of the PDF decode: 1 0 obj ..... /I1 Do /* This is the ballet CMYK Image, which ends up missing */ .... /GS4 gs /* This is pointing to resource [13,0] given below, which contains the soft mask. This should set the graphic state with a soft mask, which would then be applies to the next grahic object. The mask is a gray level binary mask which should mask out all but the border in the next image. */ /I3 Do /* This is a CMYK image of the border that we want to use with the above mask that is obtained in setting /GS4 */ ... endobj 10 0 obj << /S /Transparency /CS /DeviceCMYK >> endobj 11 0 obj << /Subtype /Form /BBox [ 0.00045 0.00065 0.99948 0.99891 ] /FormType 1 /Matrix [ 1 0 0 1 0 0 ] /Group 10 0 R /Resources 14 0 R /Length 76 /Filter /FlateDecode >> stream .00045 .00065 .99902 .99826 re W n q /GS5 gs .00045 -.00185 .99902 1.00356 re W* n /I2 Do Q endstream endobj 12 0 obj << /S /Luminosity /G 11 0 R >> endobj 13 0 obj << /AIS false /SMask 12 0 R >> endobj 14 0 obj << /ProcSet [ /PDF /ImageB ] /XObject << /I2 16 0 R >> /ExtGState << /GS5 15 0 R >> >> endobj 15 0 obj << /AIS false /SMask /None >> endobj 16 0 obj << /Length 51366 /Filter /DCTDecode /Type /XObject /Subtype /Image /Width 2199 /Height 1544 /BitsPerComponent 8 /ColorSpace /DeviceGray >> stream /* SOFT MASK DATA IS HERE */ endstream endobj With the above data, the PDF14 device fills /I1 in into its data buffer like it should. When it gets to /GS4 it does a Begin Transparency Mask. This creates a new buffer and pushes the current one on the stack. It fills the buffer with the soft mask data [16,0] (via the fill_rectangle call in PDF14). Converting the Grayscale mask to CMYK in the process. It then ends the transparency mask, doing the POP and setting ctx->maskbuf to the mask data. It then does another push_transparency_mask. At this point, it destroys ctx->maskbuf. It then creates another buffer. It then puts in [13,0] AGAIN into the buffer with the fill_rectangle in PDF14. (WHY IT IS DOING IT TWICE I DONT KNOW. THERE HAS TO BE AN ISSUE IN THE INTERPRETER) It then ends transparency mask doing a POP. Setting the ctx->maskbuf to the mask data. Now, it finally reads in the border image /I3. It does this with a fill rectangle. Of course, this blows away our ballet image as it writes into the root buffer. The mask data is obviously not used. Currently the ONLY time the mask data is ever used is when pdf14_pop_transparency_group occurs. Since we never created a transparency group we obviously never use it. I realize there was some discussions on bug 688601 about this problem. Basically, we need to have the ability to associate a softmask that is outside a transparency group with the graphic state, since this is the manner in which it really is used. Personally, I believe there should be a monochrome softmask image component in the graphic state. There is going to need to be more discussion on how best to solve this as it is a significant change that spans a lot of territory.
Created attachment 4288 [details] PostScriptTrace.txt Output of debug with -dPDFDEBUG and -Z! for the portion where the SMASK is used twice. Basically two transparency mask groups are created and destroyed prior to reading in the image that should be used with the mask. The postscript debug stuff is a bit cryptic for me, but my theory is that in this example, the Smask is defined in a graphic state referred to as /GS4 . The interpreter ends up setting into this state twice and each time, there is this Smask term that is defined to be part of the graphic state. When we encounter it we create the transparency mask group which, is blown away since we always assume a Smask is associated with an image XObject, and we create a transparency group. Here we have no such thing but rather the Smask is associated with the graphic state. See Chapter 7 page 550 in version 1.7 PDF spec.
*** Bug 690027 has been marked as a duplicate of this bug. ***
I may have been a bit premature in stating that this file is a case of a graphic state setting of a softmask outside of a transparency group. While it is true that a group is never created in ghostscript (and hence no compositing occurs with the smask), looking further at this, I am a bit confused on why object 10 does not lead to the creation of a transparency group. It is clear that the Smask defined in 13 should be associated with this defined transparency group. I placed debug statements in pdf_draw.ps to try to determine why the group is not created. Interestingly, it never even does a DoFrom process for object 11 (DoForm is defined in pdf_draw.ps). This is in contrast to another PDF file that I have with a transparency. In that case, when it resolves the form, it executes DoForm in pdf_draw.ps. I can't figure out where/how DoForm is called in the postscript code. Looking for some Postscript help on this.
This renders properly with the soft mask branch
Fixed in trunk since soft mask branch has been merged.
Changing customer bugs that have been resolved more than a year ago to closed.