pdfwrite - fix group attributes ColorSpace

Bug #705079 "Blending issue with the drop-shadow image"

This turns out to be because the new PDF interpreter was not setting the
current colour space to be the /CS from the XObject group attributes
dictionary.

Attempting to do this turned out to be well nigh impossible. We can't
(not sure why but it certainly doesn't work) use gsave/grestore to
preserve the colour space. Attempting to replicate the old PDF interpreter
in PostScript behaviour and copying the current colour and spaces led
to seg faults.

On closer inspection, however, it turns out that the only reason for
setting the current colour space is because the pdf14 compositor
discards the ColorSpace passed in from the interpreter. The interpreter
passes a gs_transparency_group_params_t structure, which cotnains an
entry for the ColorSpace, the graphics library however copies the entries
into a gs_pdf14trans_params_t which does *not* contain a ColorSpace.

I've no idea what the point of this was, but it seems mad. This commit
adds a new member 'ColorSpace' to the gs_pdf14trans_params_t
structure, and initialises it from the gs_transparency_group_params_t
structure. We then modify pdfwrite to use that instead of the current
colour space.

The PostScript and C based PDF interpreters both already initialised
that member so nothing further needed to be done there. The XPS
interpreter did not initialise that member, and so we also update it
to do so.

This fixes the bug and shows no diffs on the cluster.

Finally update the PDF interpreter, it seems that the old code
accepted a /ColorSpace in place of a /CS in the group attributes
dictionary even though this is technically invalid.

Fall back to the current colour space if no /CS or /ColorSpace is
present in the group attributes dictionary (this is illegal but
it might 'work').

Finally add a check, as per the old code, to see that the number
of components for the colour space matches the number of components
in the /BC array if one is supplied. Unlike Acrobat we choose not
to ignore the SMask if they don't match.

We do emit warnings/errors for all the above conditions.

1 files changed, 11 insertions, 2 deletions

diff --git a/pdf/pdf_trans.c b/pdf/pdf_trans.c
index df0194d73..9b7a6e589 100644
--- a/pdf/pdf_trans.c
+++ b/pdf/pdf_trans.c
@@ -251,8 +251,14 @@ static int pdfi_trans_set_mask(pdf_context *ctx, pdfi_int_gstate *igs, int color
         if (code > 0) {
             /* TODO: Stuff with colorspace, see .execmaskgroup */
             code = pdfi_dict_knownget(ctx, Group, "CS", &CS);
-            if (code < 0)
-                goto exit;
+            if (code < 0) {
+                code = pdfi_dict_knownget(ctx, Group, "ColorSpace", &CS);
+                if (code < 0) {
+                    pdfi_set_error(ctx, 0, NULL, E_PDF_GROUP_NO_CS, "pdfi_trans_set_mask", (char *)"*** Defaulting to currrent colour space");
+                    goto exit;
+                }
+                pdfi_set_warning(ctx, 0, NULL, W_PDF_GROUP_HAS_COLORSPACE, "pdfi_trans_set_mask", NULL);
+            }
             if (code > 0) {
                 code = pdfi_create_colorspace(ctx, CS, (pdf_dict *)ctx->main_stream,
                                               ctx->page.CurrentPageDict, &pcs, false);
@@ -284,6 +290,9 @@ static int pdfi_trans_set_mask(pdf_context *ctx, pdfi_int_gstate *igs, int color
             }
             params.Background_components = pdfi_array_size(BC);
 
+            if (gs_color_space_num_components(params.ColorSpace) != params.Background_components)
+                pdfi_set_warning(ctx, 0, NULL, W_PDF_GROUP_BAD_BC, "pdfi_trans_set_mask", NULL);
+
             /* TODO: Not sure how to handle this...  recheck PS code (pdf_draw.ps/gssmask) */
             /* This should be "currentgray" for the color that we put in params.ColorSpace,
              * It looks super-convoluted to actually get this value.  Really?