- From: Chris Murphy <lists@colorremedies.com>
- Date: Wed, 29 Jul 2009 11:24:11 -0400
- To: W3C style mailing list <www-style@w3.org>
- Cc: Ludger Buenger <ludger.buenger@realobjects.com>, Brad Kemper <brad.kemper@gmail.com>
- Message-Id: <F4CAFA9A-AFB3-4437-87F5-F80A9E8CFF1A@colorremedies.com>
Why even support CMYK in the first place? It's an output device dependent color model. Without an explicit color space assumed or defined by everything that comes into contact with those CMYK values, there is no way to display them correctly. I wouldn't touch this with a 10 foot pole. Such color spaces are defined by ~2-3MB ICC profiles. Well in advance of the required color management to support CMYK, I would like to think we'd revisit color management for RGB (and variants) and get that color model working correctly rather than the total haphazardness it is today. Chris Murphy Color Remedies (TM) New York, NY ---------------------------------------------------------------------- Co-author "Real World Color Management, 2nd Ed" On Jul 29, 2009, at 10:43 AM, Brad Kemper wrote: > Traditionally, CMYK values have always been percentages. Whether > this is represented with a decimal or with a percentage sign doesn't > make that much difference to me, but using a 256 range would be very > unusual to designers for that, and would require converting from > numbers they are used to using when designing for print. I would > expect both percentage (with a "%") and decimal notation to be > allowed, just as it is in rgb() and rgba(), even though the GCPM > doesn't specify. > > I don't really have any problem with an optional unit type being > used for degrees in HSL, except that I don't think many people would > actually type it, and it seems unnecessary since degrees is the only > type that can be used there. > > > On Jul 29, 2009, at 4:30 AM, Ludger Buenger wrote: > >> Hi everyone, >> >> We are currently in the process of implementing colors defined in >> the current working draft of the colors module (and the one color >> definition from the gcpm module). >> >> >> >> Regarding HSL colors: >> >> According to the working draft (http://www.w3.org/TR/2008/WD-css3-color-20080721/#hsl-color >> ), HSL colors accept three parameters. >> >> >> The first HSL color parameter represents the hue and accepts >> numeric values representing an angle and should be interpreted as >> degrees modulo 360. >> >> Since CSS knows unit types representing angles (deg, rad and grad), >> I'd like to suggest that if an explicit unit type is set, this one >> should be used, if no unit type is given it should be interpreted >> as degrees. >> Current working draft only permits numeric values. >> >> Question: does it make sense to also accept percentage values with >> 100% equaling 360 degrees? >> >> >> The second and third parameter of an HSL color represent saturation >> and lightness and are defined to be percentages. >> >> Here we also have questions: >> Does it make sense to accept numeric values if the percent symbol >> has been omitted and how should they be interpreted? >> >> Since the RGB color definition permits both percentage and numeric >> values, but numeric values are interpreted as a range from 0 to 255 >> with 255 representing 100%, to me it makes sense to handle this >> similar in HSL colors. >> But I am not a colors expert, so maybe this is a bad idea. >> >> >> >> >> Regarding CMYK colors (from the current working draft of CSS3 gcpm http://www.w3.org/TR/2007/WD-css3-gcpm-20070504/#cmyk-colors) >> : >> >> According to the example given in the gcpm working draft, the cmyk >> color function accepts 4 values being numeric float values in the >> range 0.0 to 1.0 representing the amount of color to be applied. >> >> Is there a rationale behind this allowed values definition >> differing from the definition of the allowed values in the rgb >> color function? >> >> From my point of view, I would expect the allowed values of the >> cmyk color function to be analogous to the rgb function: >> a percentage value or a value between 0 and 255 with 255 >> representing 100% - for the sole reason of being defined the same >> way as rgb colors are defined. >> >> >> >> Any comments? >> >> >> Best regards, >> >> Ludger >> >> >> -- >> Dipl.-Inf. Ludger Bünger >> Senior Software Engineer >> Product Development >> - - - - - - - - - - - - - - - - >> RealObjects GmbH >> Altenkesseler Str. 17/B6 >> 66115 Saarbrücken, Germany >> Tel +49 (0)681 98579 0 >> Fax +49 (0)681 98579 29 >> http://www.realobjects.com >> ludger.buenger@realobjects.com >> - - - - - - - - - - - - - - - - >> Commercial Register: Amtsgericht Saarbrücken, HRB 12016 >> Managing Directors: Michael Jung, Markus Neurohr >> VAT-ID: DE210373115 >> >> >
Received on Wednesday, 29 July 2009 15:26:15 UTC