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

On Tue, Sep 24, 2013 at 2:22 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

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


The compositing/blending spec doesn't talk about converting colors [1] All
the formulas (except for 4 special ones) work on individual color channels,
regardless of what they represent.

I agree we need to define a way how and when individual elements are
converted to the document's color space.

1: http://dev.w3.org/fxtf/compositing-1/