W3C home > Mailing lists > Public > www-style@w3.org > September 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 12 Sep 2013 17:31:51 -0700
Message-ID: <CAAWBYDCur6Dw5PYqP7+V-JJ7PkAeO5kbWEKJsQx_5GPZh44J5g@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
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.

~TJ
Received on Friday, 13 September 2013 00:32:38 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC