pdfwrite/PDF interpreter/transparency - identify page level groups

Bug #700376 "Color change after reprocessing PDF with Ghostscript"

The problem here lies in identifying the difference between a /Group
entry in the Page dictionary, and a Group encountered as part of an
operation during the course of a Page content stream.

To the rendering code, there is no difference, but pdfwrite needs to
be able to identify Page level groups so that it can attach them to the
Page dictionary when it writes them out.

Previously we've been doing this by detecting the fact that we haven't
started writing anything to the page stream. However, this is simply
not good enough, in the case of this bug report, the first thing that
happens is the file runs a form, which has a Group. Because we haven't
written anything to the page yet, we think its a page level Group and
emit it as such.

The problem is that in the original, we had set a constant alpha of
0.55. When we run the form that is self-contained and uses an alpha of
1, but because its in a form, the result of rendering the form is
composited with the page so far (currently nothing) with teh result that
the form contents are drawn 50% opaque.

When we come to handle this in pdfwrite, the fact that we think the
Group for the Form is at the page level causes us to write the Form
content stream in the page (and the Group for the Form is also put
in the Page dictionary), and we fail to emit a constant alpha, because
the form resets it to 1 before executing any marks. That means we
'optimise out' the change to 0.55 and the form is drawn 100% opaque.

This commit introduces a new transparency compositor operation
'PDF14_BEGIN_TRANS_PAGE_GROUP', the rendering code has been modified
to treat this as exactly equivalent to a 'PDF14_BEGIN_TRANS_GROUP' so
that there are no rendering differences.

The pdfwrite device, however, can use it to identify with certainty
that a given Group is at the Page level and treat it specially.

This results in 5 files in the test suite showing progressions, mostly
subtle, but one quite marked difference. The files are:
Altona_Technical_v20_x4.pdf, Bug691783.pdf, Bug691982.pdf, CATX3146.pdf,
x_-_no_compression_bomb.pdf
*only* when processed through the pdfwrite device.

3 files changed, 3 insertions, 3 deletions

diff --git a/xps/xpsgradient.c b/xps/xpsgradient.c
index df5d26711..cd9d3a981 100644
--- a/xps/xpsgradient.c
+++ b/xps/xpsgradient.c
@@ -998,7 +998,7 @@ xps_parse_gradient_brush(xps_context_t *ctx, char *base_uri, xps_resource_t *dic
             gs_end_transparency_mask(ctx->pgs, TRANSPARENCY_CHANNEL_Opacity);
 
             gs_trans_group_params_init(&tgp);
-            gs_begin_transparency_group(ctx->pgs, &tgp, &bbox);
+            gs_begin_transparency_group(ctx->pgs, &tgp, &bbox, PDF14_BEGIN_TRANS_GROUP);
             code = draw(ctx, root, spread_method, color_func);
             if (code)
             {
diff --git a/xps/xpsimage.c b/xps/xpsimage.c
index 7ea6a545e..16399118f 100644
--- a/xps/xpsimage.c
+++ b/xps/xpsimage.c
@@ -329,7 +329,7 @@ xps_paint_image_brush(xps_context_t *ctx, char *base_uri, xps_resource_t *dict,
         gs_setcolorspace(ctx->pgs, image->colorspace);
         gs_setblendmode(ctx->pgs, BLEND_MODE_Normal);
         gs_trans_group_params_init(&tgp);
-        gs_begin_transparency_group(ctx->pgs, &tgp, &bbox);
+        gs_begin_transparency_group(ctx->pgs, &tgp, &bbox, PDF14_BEGIN_TRANS_GROUP);
         code = xps_paint_image_brush_imp(ctx, image, 0);
         if (code < 0)
         {
diff --git a/xps/xpsopacity.c b/xps/xpsopacity.c
index 536c91806..e3a0b082c 100644
--- a/xps/xpsopacity.c
+++ b/xps/xpsopacity.c
@@ -123,7 +123,7 @@ xps_begin_opacity(xps_context_t *ctx, char *base_uri, xps_resource_t *dict,
     }
 
     gs_trans_group_params_init(&tgp);
-    gs_begin_transparency_group(ctx->pgs, &tgp, &bbox);
+    gs_begin_transparency_group(ctx->pgs, &tgp, &bbox, PDF14_BEGIN_TRANS_GROUP);
 
     return 0;
 }