Re: [css-gcpm][css-color] device-cmyk() interaction with RGB-space colors.

On Wed, Sep 25, 2013 at 4:11 AM, Chris Lilley <chris@w3.org> wrote:

> Hello Tab,
>
> Tuesday, September 24, 2013, 10:51:47 PM, you wrote:
>
> > Sorry, I should have linked this:
> > <http://dev.w3.org/csswg/css-color/#cmyk-colors>
>
> That description needs a lot of finessing, because as-written it
> introduces the general concept of CMYK and then says that device-CMYK
> is how you do that.
>
> This is absolutely not what we want to do (its no longer the 1980s).
> Instead, we should talk about CMYK, explain how its generated and
> handled in a modern colour-managed environment.
>

No. Device color is exactly what most people want.
Adobe promoted this CMS workflow in the nineties and early 2000's, but
we've learned a lot since then. Keeping it simple is key and introducing
calibrated color is anything but simple.
In addition, it caused tons of subtle problems (such as losing the black
channel or color fringing during transparency) that proved unsolvable.


>
> Another section would explain how compositing happens when the various
> colours to be composited are specified in different colourspaces.
>

Yes, that's needed somewhere.
Likely, just mapping to the RGB colorspace as early as possible (using the
simple conversion for CMYK) is enough.

I'm unsure what should happen for non-rgb targets. Maybe it's better to say
that they shouldn't change the colors and let the print system handle color
managment. For instance, if the target is a PDF file, that PDF should
contain CMYK and RGB (as sRGB) as defined in CSS,


>
> Lastly, as a special case where you really do want to specify
> unmanaged CMYK (such as for quality control test strips) device CMYK
> should be introduced as the way you do that particular thing.


No, deviceCMYK should be the way to express prepress colors.