Re: [CSS3 gcpm] CMYK colors and allowed values.

On Jul 31, 2009, at 1:57 PM, James Elmore wrote:



>
> On Jul 31, 2009, at 5:42 AM, Chris Murphy wrote:
>
>> This is all a fair point to make, but now I am wondering if CSS is  
>> a floor wax also?
>>
>> Look, I'm fine with this module supporting CMYK. My concerns, again  
>> are:
>>
>> 1. That resources that could otherwise be used to mature device- 
>> independent RGB handling in CSS are not siphoned away for dealing  
>> with CMYK. This is important for many more users of CSS than just  
>> those using this module. But better RGB handling is needed for  
>> paper-based publishing as well. There *are* RGB output devices. All  
>> desktop inkjet printers are RGB for example.
>>
>
> I just checked the three desktop inkjet printers near my computer  
> and all three are CMYK. I don't believe your last statement is  
> factual.

You determined they're CMYK how exactly? This has nothing to do with  
what ink is in the printer. It has to do with print architecture and  
the driver used. Inkjet manufacturer supplied drivers receive RGB data  
and convert to CMYK internally.


> Because of its roots and usage, CSS is often ambiguous -- where do  
> floats go? How many words fit on a line? Is this 'red' the same on  
> all monitors? It is part of the specification that, sometimes, the  
> output will look different on different days or different hardware.  
> This part of the specification -- gcpm -- is for printed materials,  
> and I agree with several on this thread that we must get as close to  
> standardization for printed materials as possible. Since CSS MAY BE  
> ambiguous, this might not be exactly what a page description  
> language or full printing suite of software would produce, but CSS  
> is too useful for too many things to throw away because it is  
> imperfect.

There is a vastly higher penalty in time and cost for screwed up print  
jobs, than merely displaying things wrong. A display does not waste  
hundreds of dollars in materials in the first few minutes of make- 
ready. When things need to work in print, and yet they don't, it  
requires an iterative approach to fix the problem. Something that for  
the examples you've listed are ignored as "bugs" or "anomalous  
behavior" and we make do and move on.

The preferred standardized format for handing off CMYK content for  
known print destinations is PDF/X-1a. It requires an Output Intent or  
an embedded ICC profile to defined its source color space. Untagged  
CMYK isn't allowed in that format. And the preferred standardized  
formats for handing off mixed RGB-CMYK content for unknown print  
destinations are PDF/X-3 and PDF/X-4 (the main difference being X-3  
doesn't allow transparency, it must be flattened; whereas X-4 allows  
live transparency). Both of these formats require embedded ICC  
profiles for RGB and CMYK data, and the specification of an Output  
Intent.

In my view, getting close to standardization for printed materials  
means modeling after these PDF/X (and also PDF/A) standards. The work  
has been done there already.

An almost equivalent analogy would be for CSS content to define  
displayed or printed text, but not what font family to use, leading  
some application down the line to make an assumption. I think most  
rational people would find it absurd if someone were to push back and  
say, "oh I think we should have plain text allowed without a font  
specified. Specifying a font family is someone else's problem. CSS  
doesn't need to know how to do that!" This is functionally the same  
thing when it comes to color. A set of CMYK values is not a color.  
It's a recipe with guessable ingredients. If you know exactly what  
those ingredients are, then you know what color those CMYK values (or  
RGB values) produce.


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

Received on Friday, 31 July 2009 18:18:18 UTC