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

On Wed, Sep 25, 2013 at 8:06 AM, Chris Lilley <chris@w3.org> wrote:

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

I think you have a misunderstanding how people work in the real world.
They don't want you to muck with their CMYK colors, just because there's a
profile mismatch.

We tried to push this workflow for years. It was a constant headache so we
don't do so anymore.


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

It does. If you draw with CMYK colors, we won't tag them with profiles.
For InDesign (which is the only application where you can do 'real' color
managment) and Illustrator, if images come in with CMYK profiles, we will
ignore the profiles.

The dialog is still there, but by default they basically turn CMS off for
CMYK. Notice how it says "preserve numbers" and "ignore embedded profiles".
"warn on profile mismatch" is even turned off!
We advise people not to change that.


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

At least it will be consistent. What else are you going to use as a device
profile? SWOP? EuroScale?
Even if you pass in a CMYK profile somehow, if it doesn't match when you
print, you don't want to use it since you want to avoid changing the color
numbers.


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


What benefit? Most (if not all) CMYK documents are using DeviceCMYK.
I doubt prepress applications and Acrobat are even honoring those profiles
by default during printing if they were attached accidentally.


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


I take it that you haven't designed a prepress application. (FWIW I wrote
the framework that does all the color handling for InDesign, Illustrator
and Acrobat.)
We should really avoid falling into this trap. Almost no one wants this
complexity.
For more info, see page 15 and on from
http://www.valleynewspapers.org/PDF/CS2_Printing_Guide_for_Prepress_Service_Providers.pdf
<http://www.valleynewspapers.org/PDF/CS2_Printing_Guide_for_Prepress_Service_Providers.pdf>(The
Adobe link is down unfortunately)

Most of this document deals with the craziness of a CMS workflow (and this
is after we greatly simplified it with the "safe CMYK" option). Later
revisions of InDesign increasingly turn off CMS and just rely on special
case handling during export.