- From: Chris Lilley <chris@w3.org>
- Date: Wed, 25 Sep 2013 17:06:25 +0200
- To: Rik Cabanier <cabanier@gmail.com>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
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