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

On Jul 29, 2009, at 4:07 PM, Brad Kemper wrote:

>
>
> Sent from my iPhone
>
> On Jul 29, 2009, at 12:19 PM, Chris Murphy <lists@colorremedies.com>  
> wrote:
>
>> But is CSS3 being designed as a command and control language for  
>> output devices like printers and printing presses?
>
> I'm talking about being able to specify the same sort of colors for  
> print as I can from a desktop publishing app (process colors  
> anyway), which do not require color management to use. Sure, color  
> management often helps, but even before it existed specifying the  
> CMYK colors for print was helpful.

It wasn't so much helpful as it was the only option. Which is exactly  
the problem now with CSS3 is that we're going to create all of this  
digital content that is explicitly designed for ONE kind of output  
process that is also undefined.

Bad idea for a modern page descriptive language.


>
>> If it's not, then /deviceCMYK is a bad idea to implement. It will  
>> guarantee random results from anyone defining color in such a  
>> manner. We have enough problems with color in CSS as it is on the  
>> web without compounding it.
>
> No more random than RGB without color management. It's really two  
> questions: 1) should CMYK be supported along with RGB, and 2) should  
> we have device independant color management. I would say yes to  
> both, but waiting for one should not stall the other.


I would say YES absolutely CMYK support should be stalled until, at a  
minimum, a default source color space is defined for it. And then  
understanding that there are many more flavors of CMYK widely in use  
than there are flavors of RGB, it should be apparent that the CSS3  
spec, if it's going to support something as arcane as CMYK at all,  
should allow for defining an alternate CMYK color space than the  
default. This could be done simply by referencing an existing standard  
characterization set from the ICC registry. An ICC profile need not be  
created, specified, or embedded.


>
>>
>> 100% magenta on a laser printer is a completely different color  
>> than 100% magenta on an inkjet.
>
> Yes, and they are both different from rgb(255,0,127). But at least  
> by specifying CMYK you are starting out with an assumed gamut that  
> is closer to what most CMYK Printers can print than with RGB.

That is only partially true and somewhat helpful if we're only talking  
about out of gamut colors. But what of the in-gamut colors? If you  
don't define the specific color space, the color is ambiguous whether  
it is out of gamut or not.

Untagged CMYK is a very crude and blunt instrument. I do not think it  
is wise, or necessary to create CSS3 with the same myopic ignorance in  
color handling as 1980's prepress. Essentially NO ONE is going to go  
to the effort to create either a style sheet, let alone actual  
content, for an extremely specific device condition.



>  Just as designers might assume something like sRGB IEC61966-2.1  
> screens for their untagged RGB output, a printer could assume  
> something like SWOP v2 for untagged CMYK output. Then if we  
> eventually can use  ICC profiles, so much the better.

CSS3 doesn't offer a way to define the source space. Big problem.

>
>>
>> We have gamuts that do not over lap between CMYK devices. How do  
>> you suppose that could be contended with if the color space is not  
>> specified along with the CMYK value?
>
> All you can do is assume some default profile, and then color manage  
> from there, if possible.


Assume where and when? Who does this? What is the workflow? I think  
it's a bad idea to bounce the interpretation of CSS to the  
application. The content should be responsible for defining itself.  
That is a major point of CSS in the first place.

In your example, you referred to Prince taking CSS in and outputting  
PDF. Well PDF is an output agnostic file format. As PDF has become  
more advanced, there are versions expressly for printing to printing  
presses and they require a standard CMYK space (or an embedded  
profile) be included in the PDF. This applies to all PDF/X- and it  
applies to PDF/A as well unless all of its content is device  
independent. The point is, it's not the job of applications or users  
to make assumptions about someone else's content. That creator should  
define it, and the spec should define a way to define it. And it  
should define a default if it's not defined by the content creator.

There are existing models that deal with this quite well in a modern  
world, and CSS3 should follow those principles if it's to be taken  
seriously with respect to color. If it can't do that, then it  
certainly shouldn't support CMYK, and subject the world to yet more  
untagged CMYK. We very nearly had purged untagged CMYK off the face of  
the planet, and now CSS3 wants to take us back to the insanity of 20  
years ago?

Unbelievable.



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

Received on Wednesday, 29 July 2009 21:09:41 UTC