Change the update_spot_equivalent_colors device method

This device method was using the current colour space to retrieve
equivalent colours for DeviceN/Separation inks, but that causes a
problem for GhostPDF because, for images, it does not set the current
colour space in the graphics state to be the image colour space.

It turns out that the two places which call this device method;
gx_install_Separation() and gx_install_DeviceN() already have the colour
space that we want to use so its simple to just pass along the colour
space, rather than forcing us to set the current space in the graphics
state.

I have updated update_spot_equivalent_cmyk_colors() so that if it is
ever called with a NULL pointer for the colour space it will fall back
to using the current colour space.

This doesn't cause any diffs, but it does mean that when pdfi draws
an image in a Separation or DeviceN space, the graphics library uses
the correct colour space to determine the spot equivalents.

1 files changed, 2 insertions, 2 deletions

diff --git a/devices/gdevtsep.c b/devices/gdevtsep.c
index 10d3b6335..657a3c870 100644
--- a/devices/gdevtsep.c
+++ b/devices/gdevtsep.c
@@ -956,11 +956,11 @@ tiffsep_decode_color(gx_device * dev, gx_color_index color, gx_color_value * out
  *  Device proc for updating the equivalent CMYK color for spot colors.
  */
 static int
-tiffsep_update_spot_equivalent_colors(gx_device * dev, const gs_gstate * pgs)
+tiffsep_update_spot_equivalent_colors(gx_device * dev, const gs_gstate * pgs, const gs_color_space *pcs)
 {
     tiffsep_device * pdev = (tiffsep_device *)dev;
 
-    update_spot_equivalent_cmyk_colors(dev, pgs,
+    update_spot_equivalent_cmyk_colors(dev, pgs, pcs,
                     &pdev->devn_params, &pdev->equiv_cmyk_colors);
     return 0;
 }