- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 29 Jul 2009 13:07:19 -0700
- To: Chris Murphy <lists@colorremedies.com>
- Cc: W3C style mailing list <www-style@w3.org>, Ludger Buenger <ludger.buenger@realobjects.com>
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. > 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. > > 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. 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. > > 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. >
Received on Wednesday, 29 July 2009 20:08:06 UTC