SVG Working Group Teleconference -- 08 Jul 2009

<trackbot> Date: 08 July 2009

ISSUE-2284

ISSUE-2284?

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

<trackbot> 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: 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 output

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

<ed> 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> http://dev.w3.org/SVG/docs/SVGTestSuite-howto.html

<scribe> ACTION: Jonathan to Review the filters-offset-02-b.svg test [recorded in http://www.w3.org/2009/07/08-svg-minutes.html#action01]

<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 http://www.w3.org/2009/07/08-svg-minutes.html#action02]

<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 elements?

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

ISSUE-2285

ISSUE-2285?

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

<trackbot> 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 sense
... 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> 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 equation

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 in?

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 well

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?

<ed> 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 same?

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 http://www.w3.org/2009/07/08-svg-minutes.html#action03]

<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].

ISSUE-2286

ISSUE-2286?

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

<trackbot> 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 http://www.w3.org/2009/07/08-svg-minutes.html#action04]

<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> 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

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

Initial value of Colour interpolation filters

<heycam> http://www.w3.org/mid/20090706235532.GB3942@arc.mcc.id.au

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

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

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

ISSUE-2279?

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

<trackbot> 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 order
... 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> http://dev.w3.org/csswg/css3-2d-transforms/#animation

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 http://www.w3.org/2009/07/08-svg-minutes.html#action05]

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

- DRAFT -

SVG Working Group Teleconference

08 Jul 2009

Attendees

Contents