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: Tue, 24 Sep 2013 14:22:32 -0700
Message-ID: <CAAWBYDDZrpmzAew+o-QMxepNgCepu3PPyG+KTA=6ZGBzU5nfbQ@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
On Tue, Sep 24, 2013 at 2:12 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> On Tue, Sep 24, 2013 at 2:06 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Tue, Sep 24, 2013 at 2:02 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> >> As such, CMYK colors must be converted to an equivalent RGB color
>> >
>> > I think you meant to reverse that . RGB colors are converted to CMYK
>> > during
>> > the printing process.
>> No, I meant what I wrote.  We *must* have RGB colors in memory, so we
>> can do compositing/blending/etc.  Those are only defined over RGB
>> colors.
> I see. Things like compositing and blending do not require color conversion
> though.
> If we extend filters, those don't require it either.

Compositing and blending are both defined in terms of RGB colors.  If
you think it can be done in CMYK space, that's cool, but it needs to
be defined, and we still need to define a sane behavior for handling
mixtures of RGB and CMYK colors.

Received on Tuesday, 24 September 2013 21:23:18 UTC

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