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.