Bug 688728

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.