Minutes, July 7 2009 SVG WG telcon




       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

08 Jul 2009


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

    See also: [3]IRC log

       [3] http://www.w3.org/2009/07/08-svg-irc


           ED, CM, AG, DS, JW




      * [4]Topics
          1. [5]ISSUE-2284
          2. [6]ISSUE-2285
          3. [7]ISSUE-2286
          4. [8]Test suite licence
          5. [9]Initial value of Colour interpolation filters
          6. [10]animateTransform with matrix-decomposed like CSS
      * [11]Summary of Action Items

    <trackbot> Date: 08 July 2009



    <trackbot> ISSUE-2284 -- Clarify how the primitive subregion affects
    the filter input and outputs for all filter primitives -- RAISED

    <trackbot> [12]http://www.w3.org/Graphics/SVG/WG/track/issues/2284

      [12] http://www.w3.org/Graphics/SVG/WG/track/issues/2284

    ED: The first one here is basically a question about how filter
    primitive subregions should effect the input and outputs
    ... looked at some demos
    ... seems that Mozilla is applying the primitive subregions to Opera

    <jwatt> what's my RRSAgent number?

    <jwatt> sorry to be late, thought it was Tuesday

    <jwatt> ah, ok

    ED: would like to clarify how they are applied
    ... in which order
    ... in the example in the issue here

    <ed> <feOffset in="SourceGraphic" x="50" y="50" width="200"
    height="200" dx="50" dy="50"/>

    ED: If you clip to the filter subregion first then apply the offset
    ... it would have a different result to doing the operations in the
    revers order
    ... spec is not clear on the order they are suppose to be applied
    ... Mozilla appears to be applying the offset first then clipping
    ... I think that is ok
    ... If you go a bit further
    ... feDisplacementMap is a bit more complex

    <jwatt> yeah

    ED: when the input images are different size
    ... when you have primitive subregion it's a bit more tricky
    ... in which coordinates systems the displacement is suppose to
    occur in

    CM: Which are the images of different sizes?
    ... the displacement map size and the input image?

    ED: Yes
    ... whether or not your suppose to read any type of data outside the
    primitive subregion for example

    CM: Do you know which would make sense for displacementMap?

    ED: I think in some cases it would be nice to clip right away
    ... but I can see why you'd want to clip last
    ... with feOffset you'd want to clip last

    CM: How currently could you get that clipping before hand if you
    wanted to?

    ED: That's a good question. I mean you could apply clipping outside
    the filter then pass it in
    ... but couldn't clip within the filter chain

    CM: What about just clip some region and not do any other filter
    operations and feed that back in.
    ... If you want to clip before hand you may want another filter clip
    primitive if you wanted to clip before filtering is applied

    DS: What's the current behaviour of authoring tools and browsers

    ED: Opera clips before currently
    ... I think there are cases where it makes more sense to clip the

    DS: Are we going to be at odds with authoring tools then?
    ... I'm concerned with what Inskape and Illustrator do
    ... I think we have a better chance of getting Inkscape changed if
    need be

    ED: I think Opera will do what Batik is doing

    CM: Do you know if there are any tests in the test suite that test
    clipping order?

    ED: No not really
    ... currently making some

    CM: So have you decided which order it should be done?

    ED: Still up for discussion

    <jwatt> JW: we could also add a feClip to clip a primitive output to
    an arbitrary clip path


      [13] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-offset-02-b.svg

    ED: This would be a test
    ... I'm not sure it's fully correct
    ... this fails in Opera 10
    ... and FireFox it appears to give some red in the first case
    ... Jwatt if you want to take a shot at analysing and reviewing the
    test that would be great

    <ed> [14]http://dev.w3.org/SVG/docs/SVGTestSuite-howto.html

      [14] http://dev.w3.org/SVG/docs/SVGTestSuite-howto.html

    <scribe> ACTION: Jonathan to Review the filters-offset-02-b.svg test
    [recorded in

    <trackbot> Created ACTION-2632 - Review the filters-offset-02-b.svg
    test [on Jonathan Watt - due 2009-07-15].

    <scribe> ACTION: Erik to Create test cases that test filter regions
    for a range of different filter primitives [recorded in

    <trackbot> Created ACTION-2633 - Create test cases that test filter
    regions for a range of different filter primitives [on Erik
    Dahlström - due 2009-07-15].

    CM: So just going back to what Jwatt was saying before
    ... do we define that clipPath property doesn't apply to filter

    ED: I think so. Filter primitive elements are not graphics elements
    ... so they don't apply.
    ... clipPath only applies to graphic and container elements

    CM: I wouldn't mind making it apply
    ... rather than introducing a new primitive

    DS: We couldn't really do that in 1.1

    ED: Probably not. Could do it in the filters module though
    ... I guess we could define it that way though

    CM: That would make it so we wouldn't have to insert these elements
    just to get clipping to apply
    ... to a filter



    <trackbot> ISSUE-2285 -- Resolving @primitiveUnits and z attribute
    discrepancies -- RAISED

    <trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2285

      [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2285

    ED: There are z attributes on feSpotLight and fePointLight
    ... and both say they are dependent on the value of primitive units
    ... we don't really define any coordinate system for the z-axis
    ... I was wondering if the formula in the issue makes that much
    ... or if we should make it not depend on the primitive units

    CM: What's the coordinate system set up, or doesn't it matter?

    <ed> [18]http://www.w3.org/TR/SVG11/filters.html#feSpotLight

      [18] http://www.w3.org/TR/SVG11/filters.html#feSpotLight

    ED: I think it doesn't really matter, just positive or negative

    CM: The Z points get put into the equations at some point
    ... so it doesn't really matter?

    ED: The points at Z are bit strange because it says at one point it
    depends on primitive units and in another
    ... place it says it doesn't

    CM: So you're pointing out the the points in Z don't depend on
    primitive units?

    ED: Not sure if that makes sense
    ... don't know why it would be good to have that square root

    CM: Probably you're going to pick a Z to get particular brightness

    ED: What's your suggested solution?
    ... unless there's some really good reason to have primitive units
    apply to this
    ... then they could be removed
    ... or the option is to correct the points at Z for feSpotLight
    ... to me it's a really arbitrary choice
    ... it's smaller change to add primitive units for Z

    CM: If it's not in the primitive units coordinate system what's it

    ED: User Space

    CM: I guess the X or Y thing needs to be fixed up
    ... regardless

    ED: I did implement this recently and made the choice of doing the
    squareroot calculation

    CM: It has to be in some coordinate system, so I guess using that
    equation seems reasonable
    ... to resolve the Z axis
    ... 1 unit along the Z axis is equal to equation
    ... and add the reference to primitive units to the points at Z as

    ED: The squareroot equation is only applied to when you have
    primitive units set to ObjectBoundingBox

    CM: Maybe it's not reasonable then
    ... because you're using the are to get a single dimensional value
    ... what would be a good thing to do?
    ... average of X and Y?
    ... the only other alternative is to allow people to explicitly set
    the coordinate system

    ED: Could be difficult to do

    CM: Did you want to test different user agents?


      [19] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-light-01-f.svg

    ED: Don't know if that one is doing anything with primitive units
    ... could probably convert it to test the units
    ... shouldn't be too difficult

    CM: In this test the size of the X and Y coordinate systems are the

    AG: Doesn't sound like it would effect people greatly
    ... probably worth going for a simple solution

    ED: Average of X and Y or squareroot equation
    ... I will make some test cases and suggest some wording to appear
    in the spec

    <scribe> ACTION: Erik to Create filter tests that test the Z units
    for feSpotLight and fePointLight and create some wording to address
    ISSUE-2285 [recorded in

    <trackbot> Created ACTION-2634 - Create filter tests that test the Z
    units for feSpotLight and fePointLight and create some wording to
    address ISSUE-2285 [on Erik Dahlström - due 2009-07-15].



    <trackbot> ISSUE-2286 -- Resolving relative values in
    @kernelUnitLength (number-optional-number) -- RAISED

    <trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2286

      [21] http://www.w3.org/Graphics/SVG/WG/track/issues/2286

    ED: There are a couple of attributes that use the optional number
    ... kernal unit length in filters
    ... how do you resolve the primitive units
    ... you have to expand the value to two values
    ... before running the filter chain
    ... given the choice of the two options in the issue
    ... I'd say expand the values first
    ... and then calculate the primitive unit scaling

    CM: I think that makes more sense
    ... Filter elements are the only one that use optional numbers?

    ED: There are a couple of places, but its similar for units

    CM: Do you know if we have tests?

    ED: We don't at the moment but I can provide some

    <scribe> ACTION: Erik to Add wording to both 1.1 2nd and the filters
    module that clarifies the usage of optional numbers for kernal unit
    length [recorded in

    <trackbot> Created ACTION-2635 - Add wording to both 1.1 2nd and the
    filters module that clarifies the usage of optional numbers for
    kernal unit length [on Erik Dahlström - due 2009-07-15].

Test suite licence

    <heycam> ACTION-2623?

    <trackbot> ACTION-2623 -- Erik Dahlström to convert the test suites
    to use the 3-clause bsd licence -- due 2009-06-19 -- OPEN

    <trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/actions/2623

      [23] http://www.w3.org/Graphics/SVG/WG/track/actions/2623

    ED: Just wondering if the conversion script has been run

    AG: All done and checked in

    ED: Wondering if I should change the copyright part in each test?
    ... if I should change it what should I change it to

    CM: I guess it would be better to have it say something
    ... with the licence URL

    ED: Do you need to link each file to the licence URL?

    CM: Need to check if it's just one file at the top or in each
    individual file


      [24] http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html

    DS: I'll find out
    ... or if someone can summarise the issue
    ... Rigo is going on vacation very soon, so should be done right

Initial value of Colour interpolation filters


      [25] http://www.w3.org/mid/20090706235532.GB3942@arc.mcc.id.au

    CM: Hans Schmucker wrote these perspective examples using
    ... he was saying the initial value should be changed

    ED: It's probably easier if the initial value was sRGB from the

    CM: Do you know of any other place where you'd want to have
    linearRGB as the default?
    ... gradients is something I can think of

    AG: Would like to find out from Chris why this is done

    DS: We should hold off on this issue

animateTransform with matrix-decomposed like CSS


    <trackbot> ISSUE-2279 -- animateTransform with matrix-decomposed
    like CSS -- RAISED

    <trackbot> [26]http://www.w3.org/Graphics/SVG/WG/track/issues/2279

      [26] http://www.w3.org/Graphics/SVG/WG/track/issues/2279

    CM: picked this as one of the issues raised on SVG 2
    ... that we hadn't discussed yet
    ... in CSS Animations when you animate a transform property
    ... it does a decomposition of the transform
    ... and transforms between the components
    ... our animate transform for non-additive transforms will animate
    the specific items in the transform attribute
    ... there is no way to do this automatic composition in a particular
    ... the issue is whether want to have this kind of animation or not

    ED: It might be
    ... You seem to be asking if we could make a new type of transform
    as the default
    ... and that's not really possible
    ... if give it an unsupported value
    ... as long as the type is ignored by the tiny user agents then
    that's fine
    ... it is possible
    ... I take it back

    CM: Would this work for if you're animating between items where they
    don't match up exactly
    ... so does anyone remember what SVG it says about this?
    ... You have to give animateTransform a type
    ... could have animateTrasform type list
    ... and give it a list of transforms

    <heycam> [27]http://dev.w3.org/csswg/css3-2d-transforms/#animation

      [27] http://dev.w3.org/csswg/css3-2d-transforms/#animation


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

    CM: Would certainly make it easier to unify the specs
    ... sounds like it's the stage where someone could propose some text
    to SVG 2

    <scribe> ACTION: Cameron to Add animateTransformType="list" with
    behaviour that matches CSS animation [recorded in

    <trackbot> Created ACTION-2636 - Add animateTransformType="list"
    with behaviour that matches CSS animation [on Cameron McCormack -
    due 2009-07-15].

Summary of Action Items

    [NEW] ACTION: Cameron to Add animateTransformType="list" with
    behaviour that matches CSS animation [recorded in
    [NEW] ACTION: Erik to Add wording to both 1.1 2nd and the filters
    module that clarifies the usage of optional numbers for kernal unit
    length [recorded in
    [NEW] ACTION: Erik to Create filter tests that test the Z units for
    feSpotLight and fePointLight and create some wording to address
    ISSUE-2285 [recorded in
    [NEW] ACTION: Erik to Create test cases that test filter regions for
    a range of different filter primitives [recorded in
    [NEW] ACTION: Jonathan to Review the filters-offset-02-b.svg test
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [35]scribe.perl version 1.135
     ([36]CVS log)
     $Date: 2009/07/08 08:05:32 $

      [35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [36] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [37]http://dev.w3.org/cvsweb/~checkout~/2002

      [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ing/in/
Succeeded: s/bright ness/brightness/
No ScribeNick specified.  Guessing ScribeNick: anthony
Inferring Scribes: anthony
Present: ED CM AG DS JW
Agenda: [38]http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSe
Found Date: 08 Jul 2009
Guessing minutes URL: [39]http://www.w3.org/2009/07/08-svg-minutes.html
People with action items: cameron erik jonathan

      [38] http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0007.html
      [39] http://www.w3.org/2009/07/08-svg-minutes.html

    End of [40]scribe.perl diagnostic output]

      [40] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Wednesday, 8 July 2009 08:17:12 UTC