A tiled pattern composed of an image with a soft mask renders all black.
Created attachment 2236 [details] L-2.pdf
Would I have access to customers' restricted/private test files, please?
Comment on attachment 2236 [details] L-2.pdf I don't think this attachment contains any customer sensitive information; so I am removing the private status.
Comment on attachment 2236 [details] L-2.pdf I am changing the attachment status back to private. Without permission from the customer, we should not make customer data public.
Created attachment 2370 [details] Much simplified testfile Ijust the faulty object, so no more private elements are inside; moreover, it's much easier to debug.
Created attachment 2371 [details] Much simplified testfile I have insulated just the faulty object, so no more private elements are inside; moreover, it's much easier to debug.
The object in problem is actually an Image XObject with a soft mask, 16 0 obj and 15 0 obj respectively (speaking about the new, much simplified test file). Ghostscript simply ignores the softmask and renders the image as is, hence a full black image shows instead of a masked one. (At least as I can see, not just SMask images but no kind of PDF14 transparencies work inside of a tiled pattern's "PaintProc" stream.) That's because /pageusestransparency operator (see definition in pdf_main.ps) returns false in an undesired way (GS searches for Image XObjects with SMask just in resourceusestransparency and annotsusetransparency but this is not enough in our case) so all subsequent transparency operations are ignored. Unfortunately forcing /pageusestransparency leave true on stack still doesn't solve the problem in our case. Despite of PDF14 compositor the softmask image is rendering as data image directly in pattern accumulator device and the result becames exactly the same. Sorry, but I'm not really familiar with PDF14 compositors yet, so I simply can't go on from this point unless Dan lends me a helping hand for solving this bug...
I reviewed this bug and everything I see indicates a problem in the PDF interpreter component as opposed to a transparency compositing issue. Therefore I'm moving the assignment to Alex.
I was operating under the belief that the "PDF Interpreter" is not only the lib folder entries, but the src folder code that operates behind it. Since that has become less clear after some deeper thought... I'm moving this bug back to my assignment.
I have spent the better part of a day looking at this and have traced it as far as knowing that the problem is related to the fact that the PDF interpreter code never calls resolvecolorspace on the Pattern colorspace. As a result, the softmask is built, but uses the wrong color space. This was uncovered by opening the PDF in Illustrator and making a minor change (dragged the clipping path a few pixels) and saving to a new PDF. This PDF runs correctly and I can see that it indeed calls resolvecolorspace on the Pattern colorspace and generates the mask correctly. I will post my modified PDF shortly.
Created attachment 2919 [details] 688728-simple-Illus.pdf.gz - produces correct results. See comments above.
Reassigning to new owner
Per request I'm resting this customer's bugs: this one still occurs with r8596.
Reassigning to Alex based on Tim's analysis that this is an interpreter problem. Alex, if it really is in the graphics library, please assign to Michael.
support has requested a status update for this problem. Please add a new comment entry or send mail to Marcos.
This problem is being fixed in the SMask branch. My patch to the PDF interpreter to find transparency in patterns installs the PDF14 compositor (properly sets pageusestransparency) and my other fixes to the pattern accumulator to use the pdf14 compositor when the pattern uses_transparency fix this file.
This was fixed with the soft mask merge.
Changing customer bugs that have been resolved more than a year ago to closed.