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/base/gdevsclass.c b/base/gdevsclass.c
index aec268939..2f757b769 100644
--- a/base/gdevsclass.c
+++ b/base/gdevsclass.c
@@ -596,10 +596,10 @@ int default_subclass_fill_linear_color_triangle(gx_device *dev, const gs_fill_at
     return gx_default_fill_linear_color_triangle(dev, fa, p0, p1, p2, c0, c1, c2);
 }
 
-int default_subclass_update_spot_equivalent_colors(gx_device *dev, const gs_gstate * pgs)
+int default_subclass_update_spot_equivalent_colors(gx_device *dev, const gs_gstate * pgs, const gs_color_space *pcs)
 {
     if (dev->child)
-        return dev_proc(dev->child, update_spot_equivalent_colors)(dev->child, pgs);
+        return dev_proc(dev->child, update_spot_equivalent_colors)(dev->child, pgs, pcs);
 
     return 0;
 }