summaryrefslogtreecommitdiff
path: root/cups
diff options
context:
space:
mode:
authorMichael Vrhel <michael.vrhel@artifex.com>2019-02-22 13:43:15 -0800
committerMichael Vrhel <michael.vrhel@artifex.com>2019-02-22 13:44:12 -0800
commit1bc4205dca71ca075af6ca95aa53a33f5a724586 (patch)
treec25ad6e0f2a99f5b8c7b7d04a7cc40ab2413f1c4 /cups
parentf89824ec77691e80b954fd0e783fc41cf6246599 (diff)
downloadghostpdl-1bc4205dca71ca075af6ca95aa53a33f5a724586.tar.gz
Bug 700584 Cups device
The RGBW color space needs to have the white value mapped properly during the encode process.
Diffstat (limited to 'cups')
-rw-r--r--cups/gdevcups.c14
1 files changed, 14 insertions, 0 deletions
diff --git a/cups/gdevcups.c b/cups/gdevcups.c
index 52d93d12b..f08a21518 100644
--- a/cups/gdevcups.c
+++ b/cups/gdevcups.c
@@ -667,6 +667,20 @@ cups_encode_color(gx_device *pdev,
ci = 0x06; /* == light cyan + yellow */
}
+ /* The entire manner that cups does its color mapping needs some serious
+ rework. In the case of the output RGBW color space, it takes a source
+ CMYK value which gs maps to RGB, cups then maps the RGB to CMYK and then
+ from there to RGBW and finally it does an encode. Unfortunately, the
+ number of color values for RGBW is 3 since it is using an RGB ICC profile
+ this means that the W mapping value from cups is lost in cmap_rgb_direct
+ So here we ensure that the W is always set to on (else we end up with a
+ blue background cast). The ideal way
+ to fix this is to move some of these odd color spaces of cups to the
+ separation device model ensuring that things are handled properly. */
+ if (cups->header.cupsColorSpace == CUPS_CSPACE_RGBW) {
+ ci = (ci << shift) | cups->EncodeLUT[gx_max_color_value];
+ }
+
/*
* Range check the return value...
*/