Colorspace management in Postscript, Ghostscript, GSView - rgb

Question

I am attempting to write some Postscript in order to produce artwork in files I can send to a printer to get some signs printed.
The printer has various requirements for PDFs, one of which is that they should use CMYK.
In all my prior use of Postscript I have used setrgbcolor and never really dealt with colorspace management, ICC profiles, etc.
One of the colours I am using is called RAL 1507 RAL 5017 (Traffic Blue) with RGB and CMYK values I obtained by using a search engine for the colour name. I checked by using an online RGB to CMYK convertor (with no specified colourspace profile)
I though I'd try setcmykcolor and created the following
%!PS-Adobe3.0
%
% Test use of CMYK in Postscript in preparation for creating a PDF/A-1a file
% for use by a commercial printer.
%
%%Pages: 1
%%Page: One 1
/Hevetica-Bold 20 selectfont
0 90 255 div 140 255 div setrgbcolor
100 100 250 100 rectfill
120 130 moveto 1 setgray (RGB: 0 90 140) show
100 255 div 60 255 div 0 10 255 div setcmykcolor
100 200 250 100 rectfill
120 230 moveto 1 setgray (CMYK: 100 60 0 10) show
100 255 div 36 255 div 0 45 255 div setcmykcolor
100 300 250 100 rectfill
120 330 moveto 1 setgray (CMYK: 100 36 0 45) show
0 0 1 setrgbcolor
100 400 250 100 rectfill
120 430 moveto 1 setgray (RGB: 0 0 255) show
showpage
%%EOF
(Forgive the DSC - it's intended to be just enough to placate GSView)
GSView 5.0 on MS-Windows 10 with Ghostscript 9.05 renders it like this
I had expected at least one of the CMYK colours to be rendered much closer to the bottom RGB colour.
The colour in question is designed for printing road-signs, so I'd be surprised if it is outside the relevant colour gamut used by commercial printers.
What do I need to do to be confident the printer will print my CMYK value with a result close to what I expect from GSView's rendering of the RGB value.

Answer 1

I don't know where you got the CMYK values from but they are not (IMO) a good representation of the RGB colour. Try 0.74 0.44 0 0.27 setcmykcolor instead.
The numbers you have used would be reasonable, if you treated them as percentages, not as values in the range 0->255. 100% Cyan, 36% magenta 0% yellow and 45% black produces quite a respectable match. I wonder if that's your mistake ?
That would be:
1 0.36 0 0.45 setcmykcolor
By the way, I think you mean RAL 5017, not 1507 which is red.
On top of that, bear in mind that you are converting an RGB colour to CMYK, then displaying that CMYK value on an RGB monitor, which involves converting it back to RGB, so some loss of precision is to be expected.
The highly simplistic calculation given in the Red Book (PostScript Language Reference Manual) is that cyan = 1 - red, magenta = 1 - green, yellow = 1 - blue. However equal values of CMYK do not generally create black, so we also apply undercolor removal.
Take the lowest value of C, M, Y, Make that value K (black). Then subtract k from each of C, M, Y. The final result is:
c = 1 - red
m = 1 - green
y = 1 - blue
k = min (c, m, y)
cyan = c - k
magenta = m - k
yellow = y - k
black = k
For your values (mapped to values from 0-1, assuming a range of 0-255);
red = 0
green = 0.353
blue = 0.549
c = 1 - 0 = 1
m = 1 - 0.353 = 0.647
y = 1 - 0.549 = 0.451
k = 0.451
cyan = 1 - 0.451 = .549
magenta = 0.647 - 0.451 = 0.196
yellow = 0.451 - 0.451 = 0
black = 0.451
so
0.549 0.196 0 0.451 setcmykcolor
That's a cheap and cheerful calculation, its intended to be done by a PostScript interpreter in a printer, so its chosen to be quick, rather than accurate. But I think you'll see that its closer than the values you were using.
For proper colour space management the RGB colours you are using would be values in a particular RGB space, for example the colour space of your monitor. You would then use the ICC profile associated with that device to turn the RGB values into values in the CIE XYZ space (a device-independent space). Then you would choose a particular destination CMYK space (eg the printer you want to use) and would use the ICC profile asociated with the destination device to go the other way, turn the XYZ values into CMYK values.
In a properly colour managed workflow, where all the devices are characterised by ICC profiles, the result is that the colour on all the devices would be as close as it possible to get to being the same.
Of course, this relies on you having everything characterised, clearly you don't.
Note that spot colours (/Separation colours in PostScript and PDF) are somewhat 'different'. These are intended to be printed using the specific ink so there's no need to characterise the values, 50% Pantone 1495 is an absolutely accurate value.
However, if your printer isn't equipped to print that colour, because for example your doing a quick check on your local CMYK printer, these colours are normally defined to have an 'alternate' representation. Ideally these would be CMYK values which will print something which is not entirely unlike the desired colour. Some ink manufacturers specify an alternate representation which is not a particularly good representation of the actual colour, arguably because they have a number of inks which map to the same colour in CMYK, so they use 'off' values to be able to tell the difference. Suspicious users have been known to comment that its done to make sure you can't do a decent print without using the manufacturers inks.....