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

On Jul 31, 2009, at 5:07 AM, Ludger Buenger wrote:

> I'd like to point out that we currently discuss something defined in  
> the
> gcpm module which has the specific purpose to define CSS extensions  
> used
> for paper-based publishing.
>
>
> I cite from the CSS3 gcpm module introduction:
>
> "This specification describes various functionality which is commonly
> used in paper-based publishing. Some of the proposed functionality
> (e.g., hyphenation and the new list style types) may also used with
> other media types. However, this specification is only concerned with
> the 'print' media type."
>
>
> So the ability to use colors defined in CMYK is targeted  
> specifically to
> applications providing CSS driven paper-based publishing using the  
> print
> media type.

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.

2. A page description language absolutely should not make it easy to  
create ambiguous content. Untagged CMYK is ambiguous. No CMYK support  
is better than ambiguous CMYK content.



> Chris Murphy wrote:
>
>> Using that logic, CSS3 should support YCbCr because that is a  
>> required
> color space for JFIF/JPEG files.
>
> I you find supporters to introduce a CSS module specifying CSS for
> applications rendering to JFIF/JPEG, that might be an option for said
> CSS module.
> You might decide yourself whether you have need for such a module.

In your example of PDF/X-1a, a set of tags referred to as the Output  
Intent are also required. They specify the intended output for the  
PDF, and are simultaneously the source profile for the content. So if  
your argument is that PDF/X-1a requires CMYK, therefore CSS needs  
CMYK, then I will argue that because PDF/X-1a requires an Output  
Intent means CSS also requires it. The PDF is invalid PDF/X-1a if it  
lacks an Output Intent.

If someone wants to make PDF/A they need the ability to define  
unambiguous RGB and CMYK. We should not be restricted to just sRGB,  
and untagged CMYK is disqualifying. The CSS should be capable of  
defining color unambiguously, and without dependency on assumed color  
spaces.


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

Received on Friday, 31 July 2009 12:42:46 UTC