Bug 691803

Summary: Ghostscript cannot set a /SMask in the graphic state using an image with /SMask attribute
Product: Ghostscript Reporter: Chris Liddell (chrisl) <chris.liddell>
Component: Graphics LibraryAssignee: Michael Vrhel <michael.vrhel>
Status: NOTIFIED FIXED    
Severity: normal CC: hafedh.trimeche
Priority: P1    
Version: master   
Hardware: PC   
OS: Linux   
Customer: 190 Word Size: ---
Attachments: test job for smask problem

Description Chris Liddell (chrisl) 2010-11-29 14:53:06 UTC 
Ghostscript cannot set a /SMask in the graphic state using an image with /SMask attribute. instead, it uses the image and ignores /SMask attribute.

The above description and the attached test is courtesy of Alex, from Bug 691157. Since Bug 691157 exposed and was diagnosed as being a separate issue, which is now fixed, I've opted to create a new bug to track this problem.

I'm assigning to Michael to investigate - if it looks like this is another interpreter issue, then you can assign back to me.
Comment 1 Chris Liddell (chrisl) 2010-11-29 14:53:42 UTC 
Created attachment 6966 [details]
test job for smask problem
Comment 2 Ray Johnston 2010-11-29 16:55:24 UTC 
Setting customer priority (190 is P1).
Comment 3 Michael Vrhel 2010-12-01 08:06:47 UTC 
This is a strange one.  There are multiple softmasks being created where I would think there should only be one.  This is in the non-clist case.
Comment 4 Michael Vrhel 2010-12-01 08:15:43 UTC 
So I am counting a total of 4 soft masks created for this thing during rendering.  The mask is getting mixed up as it ends up divided between a hard mask and an alpha plane at some point.    I will dig into the file tomorrow to understand what weird thing is going on in it.
Comment 5 Michael Vrhel 2010-12-01 18:16:10 UTC 
Testing a fix for this.  The issue was that the soft mask contains a soft mask.  In this case, when the soft mask group is popped, it really needs to blend in the alpha portion of the current transparency stack group to create the mask buffer.
Comment 6 Michael Vrhel 2010-12-02 17:10:07 UTC 
Fixed with rev 11929