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

On Jul 29, 2009, at 2:24 PM, Brad Kemper wrote:
>
> On Jul 29, 2009, at 9:25 AM, Chris Murphy <lists@colorremedies.com>  
> wrote:
>
>> With inkjet, digital presses, and electrostatic printers, why would  
>> CSS need to specify color in CMYK?
>
> Back when I primarily worked on print design and prepress, I would  
> specify flat colors in CMYK and use pre-separated CMYK image files  
> (sometimes with extra channels for spot colors, varnishes, etc.). It  
> gave me a higher level of control and predictabilty. The people I  
> know who still work primarily in print still prefer to work in CMYK,  
> even with digital production, for the same reasons. Even with  
> electrostatic, the toners are most often CMYK.

Yes if process control and color management is sloppy, then you have  
no choice but to work directly with the rudimentary control signals of  
the device. In the vast majority of estat such as color laser printers  
you don't in fact have direct control over CMYK. The signals go into a  
black box and converted to different CMYK values, reason one to  
protect the printer from designers asking a laser printer to output  
400% ink which would physical break the printer. With inkjet printers,  
if you were to ask for 100% of all the colorants, you'd get 1200% ink  
coverage with a 12-ink inkjet. All of this has been abstracted away  
from users from consumer to professional. You do not have direct CMYK  
control over such devices. In the case of desktop inkjet printers,  
CMYK is always (on all platforms) converted to RGB before the  
manufacturer's print driver accepts the handoff.

But is CSS3 being designed as a command and control language for  
output devices like printers and printing presses? 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.

>
>> It's an extremely device dependent color space.
>
> Yes, but in many situations the device is known (again, not talking  
> about serving Web pages to the public), or the results are good  
> enough and still more predictable than with converting from RGB  
> (especially where gamuts do not overlap).

100% magenta on a laser printer is a completely different color than  
100% magenta on an inkjet. They're not anything like each other. And  
when you start combining them, the secondary and tertiary colors are  
even farther off, device to device.

Again if this is going to be used as a command and control language  
embedded into hardware, I might see the point. But you're talking  
about designers defining CMYK in CSS. That is not an engineering  
context. That's a design context. Hard coding color in untagged CMYK  
so that it has exactly NO CHANCE of ever being correctly repurposed  
for some other kind of device or display is just a hideously bad idea  
for a modern descriptive language. It's not very descriptive if the  
color is going to be random. There should be required metadata to  
define the intended output process anytime CMYK is going to be  
defined. If you say, the device is known, then it should be no problem  
whatsoever to explicitly define it in the CSS code.

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?


>
>> The color you get depends on the device, paper, inkjset, ambient  
>> temperature and humidity, etc.
>
> Are you saying that all those varables are going to be part of the  
> ICC profile for the printer? Even if true, it does not cover trying  
> to print colors that are in gamut for CMYK but not RGB.

All of those variables and more can be part of the ICC profile for  
that printer, yes. It very much depends on the printer technology,  
materials used, and process control measures that can be employed. An  
ICC profile is simply a snapshot of a device's behavior at a moment in  
time.

100C, 100M, 0Y, 25K on an Epson R1900 is a color that is out of gamut  
for most any other inkjet  printer, and certainly any printing press,  
on the planet (assuming I'm limited to CMYK). So your CMYK value for  
one device is out of gamut for another. There are mechanisms for  
dealing with out of gamut colors *IF* we know what the source color  
space is. If we don't know the source color space, we have NO chance  
at all to deal with it. And by "dealing with it" I mean do the best  
job we possibly can, by prioritizing reproduction of lightness, hue  
and then chroma (in roughly that order) of the specified color.

>
>> Is CSS being used as or integrated into output device languages?
>
> I think Prince uses CSS to create PDFs for printing, and supports  
> CMYK already.

Sounds like in this instance CSS is an input or creation language. And  
PDF is the output device language. Not the reverse.


Chris Murphy

Received on Wednesday, 29 July 2009 19:20:13 UTC