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

On Sep 12, 2013, at 5:31 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Thu, Sep 12, 2013 at 3:29 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> On Thu, Sep 12, 2013 at 2:55 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>>> On Thu, Sep 12, 2013 at 1:37 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>>>> On Thu, Sep 12, 2013 at 12:54 PM, Simon Sapin <simon.sapin@exyr.org>
>>>> wrote:
>>>>> Maybe, but that’s different from the feature specified in GCPM (and
>>>>> that
>>>>> we just decided to move into Color) which does *device* CMYK, where the
>>>>> profile is intentionally unspecified.
>>>> 
>>>> Sure, but if you're showing it on screen, you have to convert it to RGB
>>>> as
>>>> some point.
>>>> What is the profile for that conversion?
>>> 
>>> An unspecified, device-dependent profile.
>> 
>> ok, in that case it might be best to do the simple conversion to RGB:
>> 
>> red = 1.0 - min(1.0, cyan + black)
>> green = 1.0 - min(1.0, magenta + black)
>> blue = 1.0 - min(1.0, yellow + black)
>> 
>> 
>> Doing the reverse during printing, you know both profiles so you can do an
>> ICC conversion. We probably want to special case rgb(0,0,0) though since
>> everyone wants that to be 100% black.
> 
> That would be a device-independent profile, which obviously goes
> against the apparent point of the function.

I think the point of device-cmyk() is to give the author more control over the output when he knows what device will be used. But colors that are in rgb space still need to be converted, and device-cmyk() can still be converted for screens, so why not have a standard way of doing so? If it is going to look like anything on the screen, it should look as close as it can without color management, and should be consistent between RGB UAs. 

I don't see the problem, then, of using device-cmyk() in a gradient or transition with rgb.

Received on Friday, 13 September 2013 14:07:56 UTC