W3C home > Mailing lists > Public > www-style@w3.org > July 2009

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

From: Chris Murphy <lists@colorremedies.com>
Date: Fri, 31 Jul 2009 15:16:38 -0400
To: W3C style mailing list <www-style@w3.org>
Message-Id: <8AD43F8D-5B58-4AA9-94A9-94070D03FF28@colorremedies.com>
Cc: David Perrell <davidp@hpaa.com>
On Jul 31, 2009, at 2:42 PM, David Perrell wrote:
>
> Clearly, RGB can't sub for CMYK. Converting 100%K, 30%C text to RGB  
> and back
> again can really muck things up. But why would anyone use CSS to  
> mark up
> documents for which appearance is critical?

There are certain objects, like text, that need to be treated  
differently when converting from RGB to CMYK, than images. Even in the  
case of CMYK content, when repurposing to another flavor of CMYK it is  
important to treat text as a unique object.


> I don't see inclusion of CMYK without profiles as disastrous.  
> Spec'ing CMYK
> colors on paste-ups didn't require printer profiles. But images are  
> another
> story, and I don't see CSS markup targeting a specific type of print  
> device.
> If included, CMYK should always be a *secondary* color spec, to be  
> used *if*
> the device supports it.

So you'd color manage images but not color manage CSS content? We have  
that very problem right now with RGB and it's a big sticking point  
when different kinds of content can and can't be color managed  
correctly. It causes discontinuity between, say a CSS background and  
the borders of neighboring images or images with transparency and  
other content where the background object should show through but  
match the color of an image object.

If the point of this CSS module is to directly drive output devices,  
this is another matter. If the point of this CSS module is to  
facilitate the creation of some other document like PDF, PostScript,  
or rastered into TIFF/JPEG/PNG then there are more negatives with  
untagged CMYK than doing it correctly from the very beginning.


>
> I fail to see the logic of a color spec in a module titled 'Generated
> Content...'.
>
> | All desktop inkjet printers are RGB for example.
>
> I believe there are drivers (e.g. Adobe PressReady, ghostscript  
> pcl3) that
> can print CMYK with standard halftone screens on CMYK HP PCL  
> printers (e.g.
> 970C, 1220C).

There are 3rd party products that can do this. Manufacturer drivers,  
the vasty majority use case, for these devices however makes them RGB.  
They have RGB output device class ICC profiles. Their driver receives  
only RGB data. If you try to send them CMYK, the sending application  
or OS will first convert the content to RGB then pass it onto the  
driver.

The point is there is such a thing as RGB output and yet CSS doesn't  
have a mechanism for that at all because it's sRGB only, and what's  
proposed is untagged CMYK. I definitely think this is a case of cart  
before the horse.




Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Received on Friday, 31 July 2009 19:17:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT