See also: IRC log
<trackbot> Date: 08 July 2009
<trackbot> ISSUE-2284 -- Clarify how the primitive subregion affects the filter input and outputs for all filter primitives -- RAISED
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
ED: when the input images are
... 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
... the displacement map size and the input image?
... 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
... 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
... 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
... 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: 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
<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
... 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
... to a filter
<trackbot> ISSUE-2285 -- Resolving @primitiveUnits and z attribute discrepancies -- RAISED
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: 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
... 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
... 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
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
... 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
... 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: 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
... 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].
<trackbot> ISSUE-2286 -- Resolving relative values in @kernelUnitLength (number-optional-number) -- RAISED
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
... 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].
<trackbot> ACTION-2623 -- Erik Dahlström to convert the test suites to use the 3-clause bsd licence -- due 2009-06-19 -- OPEN
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
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
<trackbot> ISSUE-2279 -- animateTransform with matrix-decomposed like CSS -- RAISED
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
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].
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/ing/in/ Succeeded: s/bright ness/brightness/ No ScribeNick specified. Guessing ScribeNick: anthony Inferring Scribes: anthony Present: ED CM AG DS JW Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0007.html Found Date: 08 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/08-svg-minutes.html People with action items: cameron erik jonathan[End of scribe.perl diagnostic output]