<trackbot> Date: 26 March 2009

Zakim: ??P0 is me

<ChrisL> scribenick: jwatt

<scribe> scribenick: jwatt

<ChrisL> http://dev.w3.org/SVG/modules/color/master/SVGColor.html

ED: since Antony isn't here, let's skip Compositing for now

Color module

CL: I've split the pagination and color sections in two
...: we should discuss viewportFill to see if that should be updated

<ChrisL> The solidColor element also needs to be extended to allow the ICC etc color syntaxes.

CL: we have solidColor so people don't need to specify a gradient with two stops with the same values

<ChrisL> as its a paint server lots of things can point to it and then animating it once

<ed__> ED: it's planned that stop-color will have the cielab etc color syntaxes as well, yes?

CL: if you scroll down a bit you will see the solidColor property
... I'm taking out all this stuff:

<ChrisL> i'm replacing <color> [icc-color(<name>[,<icccolorvalue>]*)] | witha single token

CL: I'm replacing the above (scattered all over) with a single token that makes it easier to read, and less likely we'll introduce errors somewhere

AG: I can propose wording and I have some diagrams

<anthony> http://www.svgopen.org/2007/papers/PublishingAndPrintingWithSVG/index.html#S8.3.2

ED: I would like to see rgba()/hsla()

CL: that's got nothing to do with color management

ED: no, but it does have to do with paint syntax

CL: sure, but I was trying to leave that to CSS so as not to overlap or potentially conflict
... the thing the cut out from CSS was an @rule for color profiling

<ChrisL> <color> cielab(<Lightness>, <a> <b>)

CL: I spent some time trying to figure out how you could do that with ICC color, but you can't really do it with the syntax

<ChrisL> so its much simpler

DS: I'm wondering if we can lowercase:

<ChrisL> ds: can we lowercase CIE-Lab | CIE-LCHab

<shepazu> CIE-LCHab to cie-lchab, etc.

<ChrisL> ag: no, because that it the spelling people would expect

<ChrisL> Thats the way that industry spells it so we can't really change it

AG: I don't think it would worry people in the printing industry

<shepazu> I'm actually talking about making it case-insensitive, not lowercasing it per se

<shepazu> for use with CSS

<ChrisL> Is it ok to group color interpolation and stop color in one section, on gradients?

<ChrisL> the main use is gradients but it also affects compositing

DS: going back to case, are we going to be using this in CSS?

<ChrisL> could say thats the preferred spelling and its case insensitive

<ChrisL> ... in cass

CL: I made a few testcases as well
...: if you have an rgb profile, do you use 0-1, 0%-100%, ...?
... the spec doesn't say

<shepazu> test cases: http://dev.w3.org/SVG/modules/color/test/svg/
...: it says it depends on the profile
... I think we should give some guidance here

<ChrisL> rgb() has 0..255 and 0% ... 100% so I prefer to stick with tat

<ChrisL> css does it that way

ED: we should definitely allow percentages

<ChrisL> http://dev.w3.org/SVG/modules/color/test/svg/paint-sRGB-004.svg

<ChrisL> http://dev.w3.org/SVG/modules/color/test/svg/paint-sRGB-002.svg

<ChrisL> fill="rgb(196,149,129) icc-color(missing, 0.1,0.2,0.3)"

<ChrisL> thats the right syntax, yeah?

<ChrisL> 'missing' points to a non-existing profile

<ChrisL> <!--- this profile will not be found -->

<ChrisL> <color-profile name="missing" xlink:href="http://example.org/not-there/foo.icc"/>

<ChrisL> ag: its correct

<ChrisL> 'deviceColor' element has waffly language about private namespaxces and stuff. i hate it.

<ChrisL> ... what you really want is to just use cmyk

<ChrisL> ag: what about hexachrome

<ChrisL> cl: good point but that shoud be color managed

<ChrisL> ag: and spot colors

<anthony> AG: E.g. CMYK and some pantone colour PMS 104

CL: the primary use case people want is unmanaged CMYK, and the spec is really unclear on that
... I want to have something that says explicitly that profiles must be used
... since Safari and Mozilla now support it
... I don't think it's a major use case to allow overriding of profiles

AG: if you have a whole bunch of images it's easier to not have to go and edit them all

CL: but it would encourage incorrect profiles
... then again for small images you probably don't want to stick a 20k profile in lots of little images

<ChrisL> sorry this is taking up so much time, but thanks for the good comments

AG: code-wise it's not hard to do though

compositing

AG: haven't addressed ED's concerns yet, but shouldn't be a big issue

DS: our webmaster is traveling, but once he's back at the end of the month we can publish again

[discussion of ED's comment]

<ChrisL> we should be able to get those comments adressed before the next publication

Transforms module

ED: we had some feedback from Dean, and he's joined the WG

<shepazu> discussion list for Transforms: http://lists.w3.org/Archives/Public/public-fx/

<anthony> http://lists.w3.org/Archives/Public/www-style/2009Mar/0344.html

DS: and there's been some feedback on our list
... this is about transforms in general
... not 3D

<shepazu> http://www.khronos.org/news/press/releases/khronos-launches-initiative-for-free-standard-for-accelerated-3d-on-web/

DS: about create a JS API
... we should monitor it
... the new list should be focused and light traffic
... focused on transforms, animation and transitions
... features SVG and CSS are going to have in common going forward
... we want to try and direct feedback on our spec on these issues to this list
... the CSS WG will try and do the same
... now that they've agreed to use a common list, and it's been created, we can publicize this

ED: the public can send email to this list

AG: I'd like to add back the perspective-origin property
... I think the overall idea that CSS has for perspective transforms is useful

DS: should we be making two different specs?
... or should both groups be making a joint spec?

ED: maybe we should have a joint telcon

DS: are the differences large enough to have two specs

CL: I'm not sure the groups will agree on syntax

DS: there's some very SVG specific text in our transforms module
... but we could split that out

AG: that could just be an extension

DS: or we could have an abstract spec, and the two groups could have reference that in their own specs

CL: that might work

DS: implementers don't want to have to deal with two different ways of doing transforms

JW: indeed

AG: well we could even end up with four or five specs (if CSS split 2D and 3D, and if we did the same)

<scribe> ACTION: Doug to arrange a joint telcon [recorded in http://www.w3.org/2009/03/26-svg-minutes.html#action01]

<trackbot> Created ACTION-2504 - Arrange a joint telcon [on Doug Schepers - due 2009-04-02].

<ed__> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0271.html

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/too/two/
Succeeded: s/stops/stops with the same values/
Succeeded: s/Transforms module/Vector Effects/
Succeeded: s/Vector Effects/Transforms module/
Found ScribeNick: jwatt
Found ScribeNick: jwatt
Inferring Scribes: jwatt
Default Present: Shepazu, ed__, jwatt, ChrisL, anthony
Present: Shepazu ed__ jwatt ChrisL anthony
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0301.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 26 Mar 2009
Guessing minutes URL: http://www.w3.org/2009/03/26-svg-minutes.html
People with action items: doug