CompatibleOverprint Mode

Ray did the interpreter work on this and Michael did the graphics
library portion.

For the interpreter:
When OP is set, change to CompatibleOverprint mode, but don't push a
transparency group or change opacityalpha when the current blendmode
is Normal or Compatible. This was determined based on the note on page
568 of the PDF 1.7 spec (section 7.6.3 in the area titled "Compatibility
with Opaque Printing"). It states:

  Note: It is not necessary to create such an implicit transparency
  group if the current blend mode is Normal; simply substituting
  the CompatibleOverprint blend mode while painting the object
  produces equivalent results. There are some additional cases in
  which the implicit transparency group can be optimized out.

After painting, if the group was pushed, pop the group, and restore the
opacityalpha and shapealpha,then restore the blendmode (if it was
CompatibleOverprint).

NB, we don't attempt to optimize any other groups hinted at in
Adobe's comment.

In addition, if we are going to an output device that handles transparency
compositor actions do not do any of the above stuff.

For the graphics library:
When doing blending in non-isolated groups with compatible overprint
the non-drawn colors must be corrected during the fill rectangles to
ensure that the proper amount is maintained with the changing group
alpha values.  This is poorly documented in the specification.
In addition, the spec is poorly written in terms of how the blend
computation is performed for overprint compatible.

The spec claims the following:

 If the overprint mode is 1 (nonzero overprint mode) and the
 current color space and group color space are both DeviceCMYK,
 then only process color components with nonzero values replace
 the corresponding component values of the backdrop. All other
 component values leave the existing backdrop value unchanged.
 That is, the value of the blend function B(Cb,Cs) is the source
 component cs for any process (DeviceCMYK) color component whose
 (subtractive) color value is nonzero; otherwise it is the
 backdrop component cb. For spot color components, the value is
 always cb.

 The equation for compositing is

	ar*Cr = (1-as)*Cb + as*[(1-ab)*Cs+ab*B(Cb,Cs)]

 Now if I simply set B(cb,cs) to cb for the case when the
 DevieCMYK value (with opm true) is zero I get

 ar*Cr = (1-as)*Cb + as*[(1-ab)*Cs+ab*Cb]

 But what I am seeing with AR is
	ar*Cr = (1-as)*Cb + as*[(1-ab)*Cb+ab*Cb] = (1-as)*Cb + as*Cb = Cb
 which is what I think we want.

 The description in the spec is confusing as it says
"then only process color components with nonzero values replace
 the corresponding component values of the backdrop. All other
 component values leave the existing backdrop value unchanged"

 which makes sense for overprinting,

 vs.

 "That is, the value of the blend function B(Cb,Cs) is the source
 component cs for any process (DeviceCMYK) color component whose
 (subtractive) color value is nonzero; otherwise it is the
 backdrop component cb."

 Which is NOT the same thing as leaving the backdrop unchanged
 with the compositing equation
 ar*Cr = (1-as)*Cb + as*[(1-ab)*Cs+ab*B(Cb,Cs)]

 For this to work, we need to carry out the operation during
 the mixing of the source with the blend result.  Essentially
 replacing that mixing with the color we have here.

1 files changed, 1 insertions, 1 deletions

diff --git a/base/gdevp14.h b/base/gdevp14.h
index 546ad2ea1..349919395 100644
--- a/base/gdevp14.h
+++ b/base/gdevp14.h
@@ -208,7 +208,7 @@ typedef struct pdf14_device_s {
     gs_blend_mode_t blend_mode;
     bool text_knockout;
     bool overprint;
-    bool overprint_mode;
+    bool effective_overprint_mode;
     int text_group;
     gx_color_index drawn_comps;		/* Used for overprinting.  Passed from overprint compositor */
     gx_device * pclist_device;