Bug 691900

Summary: pdf14 compositor should detect transparent colours better
Product: Ghostscript Reporter: Robin Watts <robin.watts>
Component: Graphics LibraryAssignee: Robin Watts <robin.watts>
Status: CONFIRMED ---    
Severity: enhancement CC: christinedelight.top85, ghostpdl-bugs
Priority: P4    
Version: master   
Hardware: All   
OS: All   
Customer: Word Size: ---

Description Robin Watts 2011-01-19 20:24:47 UTC
To fix Bug 691897, revision 12038 was committed; a small tweak to ensure that BLEND_MODE_Compatible and BLEND_MODE_Normal were always treated the same. This exposed a bug in the handling of a quality logic file PDF_1.7_FTS/fts_08_0815.pdf.

A shading that included transparency (a softmask, I believe) was used to fill a path. Because this shading was plotted as a solid colour using the Normal blend mode, update_lop_for_pdf14 decided that it was safe not to set the pdf14 lop bit. This meant that the stroke code stroked each segment of the path separately, resulting in overrendering where the segments overlap on non solid sections of the path.

The fix (committed as revision 12039) is to modify update_lop_for_pdf14 so that it checks the current color for transparency, and sets the bit if any is found.

This works well for type 1 patterns, but the test is rather blunt for type 2 patterns; currently all type 2 patterns are held to be transparent.

It was suggested that I look at the 'has_transparency' field of the saved pattern instance, but this is (almost) always set to true before update_lop_for_pdf14 is called, so wouldn't help.

The code now gives the correct result, but could be enhanced with a better test to allow the fast code to be used in more instances.
Comment 1 Ken Sharp 2023-05-11 10:23:49 UTC
Don't know if the new PDF interpreter helps here but I feel sure we can do *something* with it to properly set use of transparency.