On Sat, Dec 19, 2009 at 2:55 PM, Jon Cruz <jon@...18...> wrote:
I think we've hit the point where we need to revisit our rendering and such to include more than just RGB.
This bug is one example: "Export to TIFF to support CMYKA color" https://bugs.launchpad.net/inkscape/+bug/492402
It looks like to be able to solve this case, we would need to be able to have our engine render to four-channel CMYK in order to preserve data. Simply rendering to RGB and then converting to CMYK using LittleCMS won't work, since black ink separation will be lost, etc.
Illustrator (these days) handles this in a sane way IMO. There is a switch for the Document Color Mode - RGB or CMYK. When selecting/creating a color in RGB mode, RGB sliders are presented and vice versa in CMYK mode (actually, you can use any sliders in any mode - it just gets converted on the fly to match the doc's color mode - but not really on-topic). What makes this sane to me is that you never end up with a mix of RGB and CMYK in the same document - which can be a nightmare when getting ready for final output.
So yes - I think it would be nice to store/render CMYK values inside Inkscape. Conversion via lcms would be nice to convert a color from RGB to CMYK *inside* Inkscape, but if I specify a color as c0m100y100k0 and save a TIFF, I would expect everything filled with that color to be 100% black on the MY channels, and 100% white on the CK channels. Trying to get the same result from RGB (with lcms) would be a crap-shoot at best. Another use case: rich black. Some print companies recommend/specify a black that is a particular formula: eg 60%C 40%M 40%Y 100%K.
Also, could we perhaps get away with export by rendering n channels, each being grayscale?
I think so. I know that's how to handle spot channels - and I think CMYK channels are similar - but it's been a while since I looked at the TIFF spec.
My 0.02 from a pre-press/dtp perspective.
Chris