Re: [CSS3 Colors] HSL colors, hue and allowed values, [CSS3 gcpm] CMYK colors and allowed values.

On Jul 30, 2009, at 11:18 AM, Brad Kemper wrote:

> On Jul 29, 2009, at 2:08 PM, Chris Murphy wrote:
>
> I agree that a default profile for untagged CMYK should be included  
> in the spec. Do we know if Prince or PDFreactor currently makes any  
> profile assumptions along those lines? SWOP, perhaps?

Don't know. But if CSS is going to optionally support CMYK, then if it  
is used a requirement must be that the color space be defined. I think  
it's unlikely you're going to get agreement on a default CMYK space to  
use, because there isn't a single ubiquitous CMYK space. There is  
widespread global agreement that sRGB is an appropriate default RGB  
space to use, there is nothing like that for CMYK. Adobe ships  
different CMYK defaults based on region.


>
> On Jul 30, 2009, at 7:37 AM, Chris Murphy wrote:
>
>> And in particular there is no case to be made for subjecting the  
>> planet to a page description language that is incapable of  
>> unambiguously defining color.
>
> Well, we already have that (regarding RGB, at least), don't we,  
> inasmuch as CSS can be called a page description language? RGB  
> colors on a Web page can vary widely from monitor to monitor, and  
> from printer to printer.


No we don't have that with RGB because the spec very clearly says it's  
sRGB in all cases. The problem is that it can't be anything other than  
sRGB. That oversight should be fixed before efforts to support CMYK.  
Just like it should be supported before device-N.

Display of web colors vary due to implementation problems*. Not a  
problem in the CSS spec. RGB values are made unambiguous by reference  
to sRGB. That implementations fck this up, is not the fault of CSS.

If CSS supports untagged CMYK, it starts out ambiguous from the very  
beginning. Only ambiguity and inconsistent interpretation of CSS will  
follow, and *THAT* will be CSS's fault.



* implementation problems, i.e. web browsers that do not assume sRGB  
as the source color space for all web content, converting to an  
appropriate display profile specified by the OS for the attached  
display. Firefox does optionally do this now in version 3.5, which is  
Very Good Thing. By default, Safari 3 and 4, and Firefox 3.5 will  
honor embedded ICC profiles in images, and convert them to the system  
defined display profile. And thus these images do display much more  
consistently among different displays. But the only reason why this is  
even possible is getting the architecture established correctly well  
in advance, and there are still problems that we need to work on.  
Adding untagged CMYK to CSS will compound problems substantially, it  
will not fix them. That it can fix very specific problems is a  
demonstration of how we need *better* abstraction, and better  
implementation of unambiguous color.

So, if CMYK, then it *MUST* be tagged CMYK. That would have to be a  
requirement. I seriously doubt you're going to get agreement around  
the world on a default CMYK for the planet. You can certainly publish,  
and cite recommended regional defaults, but the code itself is going  
to have to, unlike RGB, explicitly state that "the CMYK values in this  
document are CGATS TR 005" (i.e. SWOP 2006 on #5 stock as there are  
different kinds of SWOP).


Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"

Received on Thursday, 30 July 2009 15:42:57 UTC