Created attachment 13727 [details] Patch for handling CMY color space CMY output device (e.g. dye sublimation printer with cupsColorSpace=4) with the CMY colors (e.g. via PostScript setcmykcolor) produce incorrect color with -dUseFastColor=false (due to lack of profile and mistaking three channel CMY color space to be RGB), and inverted color with -dUseFastColor=true (also due to mistaking CMY color space to be RGB). Only RGB color input result in approximately sensible output, as they are passed as RGB values internally, converted into CMYK using the default ICC profile, and then with the K values added back to C, M, Y. Not most debilitating consequence is, with Ghostscript 9.x, it became impossible to produce profiling targets for CMY output devices (i.e. with -dUseFastColor=true). In order to pass through the CMY color space information properly, various functions in gsicc*.c and gxcmap.c needs to test for dev->color_info.polarity before assuming a three channel color space is RGB. Then the function cmap_cmyk_direct also needs to handle dev_proc(dev, get_color_comp_index) returning -1 for "Black".
OK. I can understand the need for the direct printing of CMY for profiling. I will review this patch.
So I am changing this to an enhancement. There are potential issues that I can see mainly related to transparency and color management with the solution that the reporter has given. There are probably several places in the code where we do testing for number of channels equal to three and assume that it is an RGB model. I think what I will do is create a psdcmy device which will be a cmy planar output device that would be useful to have as an example that people can see and emulate if they want.