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

Hello Rik,

Wednesday, September 25, 2013, 4:42:59 PM, you wrote:






> 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.

Well, that explains why you have been arguing against or
misrepresenting/misunderstanding colour management for the last couple
of years in the SVG WG, all the while claiming that you understood it
and (apparently) were in favour of it.

Thanks at least for stating your position clearly: you don't want any
colour management on the Web.

I note that Adobe products still have a whole preferences section for
setting up the RGB and CMYK profiles to be used, so I conclude that
your position and Adobe's official position don't coincide?

>  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. 

OMG we really are back in the 1980s? C = 1.0 - R and all that?  Total
mystery-meat colours?

> 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,

 So you are saying that PDF should continue to benefit from
colourmanaged colours (there is a substantial part of the PDF spec
dealing with this) while the Web should not? I can see how that would
be a benefit for selling PDF but not how it would benefit the Web in
any way.

>  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. 

No, it shouldn't.

-- 
Best regards,
 Chris                            mailto:chris@w3.org

Received on Wednesday, 25 September 2013 15:06:29 UTC