Bug 691891

Summary: Potential bug in transparent ROP operations
Product: Ghostscript Reporter: Robin Watts <robin.watts>
Component: Graphics LibraryAssignee: Default assignee <ghostpdl-bugs>
Status: RESOLVED INVALID    
Severity: normal    
Priority: P4    
Version: master   
Hardware: All   
OS: All   
Customer: Word Size: ---

Description Robin Watts 2011-01-17 11:15:17 UTC 
When performing rop operations in gdevmr8n.c, we can optionally have the S or T planes transparent.

The current code implements this as meaning that if either S or T is set to have transparency enabled, then S or T being the highest color index possible on entry (0xFF in 8 bit modes, 0xFFFFFF in 24 bit modes) will be treated as being transparent. This means that the result of the rop is assumed to be transparent too.

For certain values of rop, however, the input values of S or T may be ignored; it seems unlikely that S being 0xFF should cause the output of the rop to be transparent when all other possible values of S are ignored.

This should be tested, and (if there is indeed a problem) it should be fixed.
Comment 1 Robin Watts 2011-01-17 11:19:47 UTC 
Actually, on closer examination of the source, it looks like we're safe.

 if (!rop3_uses_S(rop))
     const_source = 0;

So in the event that S is ignored, we can never match the transparent index anyway.