Minutes, 26 Mar 2009 SVG WG telcon

Hello public-svg-wg,

Minutes of the 26 March 2009 SVG WG telcon are at
http://www.w3.org/2009/03/26-svg-minutes.html

and below as text.

                   SVG Working Group Teleconference

26 Mar 2009

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0301.html

   See also: [3]IRC log

      [3] http://www.w3.org/2009/03/26-svg-irc

Attendees

   Present
          Shepazu, ed__, jwatt, ChrisL, anthony

   Regrets
   Chair
          SV_MEETING_CHAIR

   Scribe
          jwatt

Contents

     * [4]Topics
         1. [5]Color module
         2. [6]compositing
         3. [7]Transforms module
     * [8]Summary of Action Items
     _________________________________________________________



   <trackbot> Date: 26 March 2009

   Zakim: ??P0 is me

   <ChrisL> scribenick: jwatt

   <scribe> scribenick: jwatt

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

      [9] 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>
   [10]http://www.svgopen.org/2007/papers/PublishingAndPrintingWithSVG/
   index.html#S8.3.2

     [10]
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:
   [11]http://dev.w3.org/SVG/modules/color/test/svg/
   ...: it says it depends on the profile
   ... I think we should give some guidance here

     [11] http://dev.w3.org/SVG/modules/color/test/svg/

   <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>
   [12]http://dev.w3.org/SVG/modules/color/test/svg/paint-sRGB-004.svg

     [12] http://dev.w3.org/SVG/modules/color/test/svg/paint-sRGB-004.svg

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

     [13] 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="[14]http://example.org/not-there/foo.icc"/>

     [14] 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:
   [15]http://lists.w3.org/Archives/Public/public-fx/

     [15] http://lists.w3.org/Archives/Public/public-fx/

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

     [16] 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>
   [17]http://www.khronos.org/news/press/releases/khronos-launches-init
   iative-for-free-standard-for-accelerated-3d-on-web/

     [17]
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
   [18]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__>
   [19]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/027
   1.html

     [19] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0271.html

Summary of Action Items

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

   [End of minutes]

Received on Thursday, 26 March 2009 21:17:32 UTC