Improve client memory handling for colour spaces and patterns

Colour spaces have had a client_data member for some time (only used
with Pantone colour replacement) but no means to signal to the client
that a colour space was going to be freed.

In addition, its terribly hard for an interpreter which uses complex
colour spaces (such as Separation and DeviceN, for Patterns see below)
to reliably track when a colour space is freed.

This commit adds a new 'interpreter_data' pointer to hold data allocated
by the interpreter which is associated with a colour space. We also add
an 'interpreter_free_cspace_proc' to be called when a colour space is
about to be freed. This gives the interpreter an opportunity to clean
up the memory it has associated with the colour space.

Similarly pattern instances (as opposed to Pattern colour spaces) have
long had a client_data member, which was previously stored in the
'template' (which is a terrible misnomer) for both type 1 and type 2
patterns. However there was no procedure to notify the client when the
pattern was freed! The PCL interpreter (which was the only one using
this type of pattern) dealt with this by replacing the 'free' routine
in the structure with its own routine which first freed the client data
and then called the original free routine. This seems like a hack.

This commit moves the client_data out of the pattern instance and into
the pattern structure proper. It also adds a 'notfy_free' member which
holds a pointer to a function to be called when a pattern is freed. This
gives the client a reliable opportunity to clean up the client_data.

These changes involve updating the PostScript, PCL and XPS interpreters
to point to the new location of the client_data, as well as similar
changes in the graphics library. pixmap patterns now use the notify_free
functio0n instead of patching over the structure's free routine.

1 files changed, 3 insertions, 4 deletions

diff --git a/xps/xpstile.c b/xps/xpstile.c
index 95b636c2f..933e757a3 100644
--- a/xps/xpstile.c
+++ b/xps/xpstile.c
@@ -62,8 +62,7 @@ xps_paint_tiling_brush_clipped(struct tile_closure_s *c)
 static int
 xps_paint_tiling_brush(const gs_client_color *pcc, gs_gstate *pgs)
 {
-    const gs_client_pattern *ppat = gs_getpattern(pcc);
-    struct tile_closure_s *c = ppat->client_data;
+    struct tile_closure_s *c = pcc->pattern->client_data;
     xps_context_t *ctx = c->ctx;
     gs_gstate *saved_pgs;
     int code;
@@ -200,7 +199,7 @@ static int
 xps_remap_pattern(const gs_client_color *pcc, gs_gstate *pgs)
 {
     gs_client_pattern *ppat = (gs_client_pattern *)gs_getpattern(pcc);
-    struct tile_closure_s *c = ppat->client_data;
+    struct tile_closure_s *c = pcc->pattern->client_data;
     xps_context_t *ctx = c->ctx;
     int code;
 
@@ -347,7 +346,6 @@ xps_parse_tiling_brush(xps_context_t *ctx, char *base_uri, xps_resource_t *dict,
         gspat.PaintType = 1;
         gspat.TilingType = 2;
         gspat.PaintProc = xps_remap_pattern;
-        gspat.client_data = &closure;
 
         /* We need to know if this tiling brush includes transparency.
            We could do a proper scan, but for now we'll be lazy and just look
@@ -384,6 +382,7 @@ xps_parse_tiling_brush(xps_context_t *ctx, char *base_uri, xps_resource_t *dict,
         sa = gs_currentstrokeadjust(ctx->pgs);
         gs_setstrokeadjust(ctx->pgs, false);
         gs_makepattern(&gscolor, &gspat, &transform, ctx->pgs, NULL);
+        gscolor.pattern->client_data = &closure;
         gs_setpattern(ctx->pgs, &gscolor);
         /* If the tiling brush has an opacity, it was already set in the group
            that we are filling.  Reset to 1.0 here to avoid double application