This section on "rendering params" calls out special handling needed when transparency is used in combination with transfer functions. Specifically, there are many cases when the pdf14 compositor should ignore the trasfer function and currently (after the fix to Bug 695904) it consistently applies the transfer function. This is not likely to be very visible now that we are consistent with using the transfer function for all objects and we will need to create some test files for this.
Most likely I will work on this, so assigning it to myself rather than to Michael Vrhel.
Dear Ray, as far as I can see neither Adobe PDF engine nor Harlequin RIP do conform to that special handling. Instead, they follow a much easier way: the transfer function is ALWAYS and IMMEDIATELY applied and the blending operation is performed on the ALREADY "transferred" colors. There is an easy way to show this. Inside the attached simple PDF you have 2 gray rectangles with different shades of gray, two different transfer functions being used for each one. Each rectangle (hence the overlapped portion as well) is painted using "Multiply" blending mode. The first rectangle’s shade: 0.2 (R=G=B); transfer function: f ( x ) = 1 - x The second one’s shade: 0.6 (R=G=B); transfer function: f ( x ) = x/2 + 0.5 In conformity with PDF Reference no transfer function should be applied as these colors are not fully opaque, moreover, if taking the PDF reference seriously in no circumstances a transfer function should be applied BEFORE the blending operation would occur. However, both of Adobe and HQ output indeed show two light rectangles with a shade of 0.8 (as the transfer function would have been applied in both cases), and the overlapped zone has a gray shade of ~0,64 – exactly the product of the two shades (as the blending would have been performed after the transfer function)! See attachment. To be honest, this approach would be much more convenient not just for GS, but for me as well as it may greatly simplify the StudioRIP’s own transparency engine. So my recommendation is to follow our competitor’s way. The problem is though that Ghostscript currently seems to ignore the transfer functions completely. Just try this file with any of RGB or CMYK drivers and the result will be absolutely the same (GS9.17). Please check this issue first, it looks like a bug!
Created attachment 11872 [details] The test PDF
Created attachment 11873 [details] Harlequin (and APPE) output
Created attachment 11874 [details] GS output, all transfer functions ignored
As I can see the transfer function ignoring issue is already fixed in Bug695904, forgive my inattention (BTW the fix hasn’t been included yet in the latest version, that’s why I thought it still persisted). So the only question left is whether it’s worth to implement the “arcane” handling of transfer functions described in PDF 1.7 Ref Manual section 7.6.4 or not – as even our big competitors seem to consistently ignore it. My customer request is that even if you made the changes you would leave a possibility to use GS in “legacy” mode, that is, to keep the current behavior, maybe by introducing a switch for this purpose. But my highest recommendation is to leave things as is and don’t spend precious time and resources for this modification. (A good supplementary reason why it shouldn’t be implemented: many applications adjust the correction curves to an image by modifying the current transfer function in the graphic state, none the less that this method is not recommended by Adobe. In this case it’s especially desirable to apply the transfer function first and just after that the blending.)
11
(In reply to realname from comment #7) > 11
This problem still occurs in the current master branch of Ghostscript.
I'm going to close this one. It's been 6 years and we don't have an actual bug report. In addition the PDF 2.0 specification deprecates transfer functions. We can rethink this if anyone ever opens an actual report.