Re: Minutes, Wednesday April 22, 2009

On Wednesday, April 22, 2009, 3:51:30 PM, Alex wrote:

AD> Hi All,

Hi Alex.

The minutes are a bit terse and in the portion you quoted don't precisely record my recollection of the discussion (Anthony, I know you were talking and minuting, and I was talking ninety to the dozen so no worries) so I'm going to add clarifying statements and if anyone disagrees, please say so.

For context, see my notes sent in just before the call
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/att-0057/color-notes.txt
which are also a bit terse, written mainly for myself to keep track and them mailed in to the group.

in particular:

> number format?
> - recent telcon decided on int 0..255  and percent 1.234% for floats
> - svg 1.1 says float, usually in range 0..1, no %

In a recent telcon (I thought
http://www.w3.org/2009/03/30-svg-minutes.html
but its not mentioned) we were discussing the numeric parameters to Icc-color() and seemed to agree on the same as rgb() in other words integers (0..255) represent a value x/255 and floats are represented as a percent to distinguish them from integers (so that 0 and 1 are unambiguous, 1 means 1/255 and if you want 1.0 then say 100%).

However, I went back and checked and that's not what SVG 1.1 says
http://www.w3.org/TR/SVG11/painting.html#SpecifyingPaint

The comma-separated list (with optional white space) of <icccolorvalue>'s is a set of ICC-profile-specific color values, expressed as <number>s. (In most cases, the <icccolorvalue>'s will be in the range 0-to-1.)

So the discussion today was about whether to 

a) stick with our earlier decision with 0..255 and 0.0%...100.0% as the normal range for in-gamut colours, thus needing an erratum for SVG 1.1, or
b) stick with SVG 1.1, the floats as 0.0..1.0 syntax  for in-gamut colours.



AD>         In regard to SVG Color:

AD> --Original Message--:

>><snip/>

(Cameron was asking if existing profiles actually have tables that cover the range outside 0..1)

>>    CL: I don't know
>>    ... some of them allow negative colors to express out of gamut
>>    colours

>>    <ChrisL> fairly sure that some allow > 1.0 for headroom; believe
>>    trhat some cms allow negative values and others clip

As I said in IRC, Im fairly sure that at least some profiles have tables or formulae that cover values greater than 1.0 (as you said below, its needed for fluorescent colours as an example).

I'm less sure about existing profiles having tables that handle negative values. in terms of colorimetry of course negative values have meaning, the original CIE matching experiments in 1931 required the use of negative values to express a colour match (which was done by adding light to the patch 'to be matched', amounting to a negative value). Where I am unsure is the extent to which

a) existing profiles
b) existing CMS

actually specify or allow negative values. But thats a discussion of implementation limitations, not an argument for dissalowing out of source gamut values. The discussion today was about syntaxtic choices, and the discussion about out of range values was tangential.

>>    CM: I think 0 to 1 makes more sense

(meaning option b) 

>>    CL: Which would be compatible with what 1.1 says
>>    ... values greater than 1 or less than 0 would be out of the profile
>>    gamut but no necessarily out of the target gamut
>>    ... I'd be fine with that

(which also means option b)

>>    RESOLUTION: A float in the range 0 to 1 like SVG 1.1 and no
>>    Scientific notation

(which is overly terse, and means we picked option b).

>>conformance

AD> Fluorescent colours require values > 1. So conformance-wise
AD> the resolution is OK, but implementations should be free to
AD> represent values > 1 and < 0.

Agreed. They are. No change from SVG 1.1 there.
The grammar I am putting together merely says its a float.


AD> Also, the resolution for no scientific notation is a bit silly.
AD> It's OK to not require it for conformance, but if an implementation
AD> chooses to parse scientific values that are in the 0->1 range, then
AD> it should be allowed (BTW, I do).

You have a point. Its not clear from SVG 1.1 if sci.notation is allowed or not. Given that the realistic range for a colour channel is perhaps -0.3 to + 1.7 or so, sci.notation seems like overkil and would merely add an "E00" to the end of the numbers.

The question then becomes, whether is more burden to require it (its allowed other places, specifically attributes which are not properties (ie not presentation attributes)) or more burden to dissallow it.

Not considered on the call, but relevant, is that we are discussing a value of type paint. fill and stroke take values of type paint, and fill and stroke are presentation attributes ie represent properties. Thus,  a closer reading of the SVG 1.1 spec on numbers
http://www.w3.org/TR/SVG11/types.html#DataTypeNumber

  "Thus, for conformance with CSS2, any property in SVG which 
  accepts <number> values is specified in decimal notation only."

should have led us to the conclusion that sci.notation was already forbidden there for SVG 1.1.

So, no change in fact from SVG 1.1 there either.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Wednesday, 22 April 2009 16:35:32 UTC