- From: Rotan Hanrahan <Rotan.Hanrahan@MobileAware.com>
- Date: Wed, 31 May 2006 21:45:32 +0100
- To: "Chris Lilley" <chris@w3.org>
- Cc: <public-diselect-editors@w3.org>
Yes, of course. That's what I get for trying a quick copy/paste. I take it that the revised definition fits with your understanding of color properties and that it resolves the anomoly. Whether or not the function itself is useful is a separate issue. The starter functions are merely to ensure that DI-Select can build upon existing Media Queries with minimal effort. Obviously people will want to extend DI-Select with their own functions, and that's when the fun begins. Regards, ---Rotan. -----Original Message----- From: Chris Lilley [mailto:chris@w3.org] Sent: 31 May 2006 21:35 To: Rotan Hanrahan Cc: public-diselect-editors@w3.org Subject: Re: bits per color component. On Wednesday, May 31, 2006, 10:17:15 PM, Rotan wrote: RH> Yes, I think we've noticed that anomoly. The starter functions in RH> DISelect are merely wrappers around the Media Queries functions, so RH> the interpretation should be exactly the same. I'm sure the wording RH> can be clarified. With this in mind, and observing the MQ definition RH> [1] I think the definition should be: RH> 'In a device with indexed colors, the di-cssmq-color function will RH> return the minimum number of bits per color component in the lookup RH> table.' a 5:6:5 system is not indexed - it has no palette. Its a truecolor (well, hicolor) system. So just "the di-cssmq-color function will return the minimum number of bits per color component" RH> Thus, for the common case of 5 bits red, 6 bits green, 5 bits blue RH> (16 bits total), "di-cssmq-color(8) > 5" would be false. (Because RH> "5 > 5" is false.) Yes. RH> -----Original Message----- RH> From: public-diselect-editors-request@w3.org RH> [mailto:public-diselect-editors-request@w3.org] On Behalf Of Chris RH> Lilley RH> Sent: 31 May 2006 20:56 RH> To: public-diselect-editors@w3.org RH> Subject: bits per color component. RH> Hello public-diselect-editors, RH> under 9.9 The di-cssmq-color function RH> http://www.w3.org/TR/2005/WD-cselection-20050502/#sec-dcn-cssmq-colo RH> r RH> I read: RH> "number of bits per color" RH> Please clarify this by changing to "number of bit per color component" RH> which is, I think, the assumed meaning. For example, a truecolor RH> display with 8 bits of red, 8 bits of green and 8 bits of blue would RH> be described here as having 8 bits, not as 24 bits, so RH> di-cssmq-color(8) < 9 RH> would be true. RH> The wording needs to be clarified because it is common to talk of RH> both the number of bits in total and also the number of bits per RH> component. A typical computer display might be described as a "24bit RH> display" and a higher quality, medical imaging display might be described as a "10 bit" RH> display (10 per component; 30 in total). RH> Also, for the common case of 5 bits red, 6 bits green, 5 bits blue RH> (16 bits total) is di-cssmq-color(8) > 5 true or false? -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Wednesday, 31 May 2006 20:45:38 UTC