06:30:12 <RRSAgent> RRSAgent has joined #svg
06:30:12 <RRSAgent> logging to http://www.w3.org/2009/07/08-svg-irc
06:30:14 <trackbot> RRSAgent, make logs public
06:30:16 <trackbot> Zakim, this will be GA_SVGWG
06:30:16 <Zakim> ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start now
06:30:17 <trackbot> Meeting: SVG Working Group Teleconference
06:30:17 <trackbot> Date: 08 July 2009
06:30:44 <Zakim> GA_SVGWG()2:30AM has now started
06:31:02 <heycam> Zakim, who is on the call?
06:31:02 <Zakim> On the phone I see no one
06:33:43 <heycam> Chair: Cameron
06:33:51 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0007.html
06:37:45 <ed> Present: ED, CM, AG, DS
06:38:11 <anthony> Topic: ISSUE-2284
06:38:14 <anthony> ISSUE-2284?
06:38:14 <trackbot> ISSUE-2284 -- Clarify how the primitive subregion affects the filter input and outputs for all filter primitives -- RAISED
06:38:14 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2284
06:39:52 <anthony> Present: ED, CM, AG, DS, JW
06:40:04 <jwatt> jwatt has joined #svg
06:40:23 <anthony> ED: The first one here is basically a question about how filter primitive subregions should effect the input and outputs
06:40:32 <anthony> ... looked at some demos
06:40:44 <anthony> ... seems that Mozilla is applying the primitive subregions to Opera
06:40:47 <jwatt> what's my RRSAgent number?
06:41:07 <jwatt> sorry to be late, thought it was Tuesday
06:41:12 <jwatt> ah, ok
06:41:15 <anthony> ... would like to clarify how they are applied
06:41:18 <anthony> ... in which order
06:41:27 <anthony> ... in the example in the issue here
06:41:29 <ed> <feOffset in="SourceGraphic" x="50" y="50" width="200" height="200" dx="50" dy="50"/>
06:41:49 <anthony> ED: If you clip to the filter subregion first then apply the offset
06:42:05 <anthony> ... it would have a different result to doing the operations in the revers order
06:42:15 <anthony> ... spec is not clear on the order they are suppose to be applied
06:42:37 <anthony> ... Mozilla appears to be applying the offset first then clipping
06:42:44 <anthony> ... I think that is ok
06:42:48 <anthony> ... If you go a bit further
06:42:57 <anthony> ... feDisplacementMap is a bit more complex
06:43:04 <jwatt> yeah
06:43:05 <anthony> ... when the input images are different size
06:43:15 <anthony> ... when you have primitive subregion it's a bit more tricky
06:43:29 <anthony> ... in which coordinates systems the displacement is suppose to occur ing
06:43:33 <anthony> s/ing/in/
06:43:43 <anthony> CM: Which are the images of different sizes?
06:43:57 <anthony> ... the displacement map size and the input image?
06:43:59 <anthony> ED: Yes
06:44:27 <anthony> ... whether or not your suppose to read any type of data outside the primitive subregion for example
06:44:41 <anthony> CM: Do you know which would make sense for displacementMap?
06:44:51 <anthony> ED: I think in some cases it would be nice to clip right away
06:45:01 <anthony> ... but I can see why you'd want to clip last
06:45:09 <shepazu> q+ to ask what ASV/Illustrator do
06:45:26 <anthony> ... with feOffset you'd want to clip last
06:46:02 <anthony> CM: How currently could you get that clipping before hand if you wanted to?
06:46:25 <anthony> ED: That's a good question. I mean you could apply clipping outside the filter then pass it in
06:46:34 <anthony> ... but couldn't clip within the filter chain
06:47:39 <anthony> CM: What about just clip some region and not do any other filter operations and feed that back in.
06:48:08 <anthony> ... If you want to clip before hand you may want another filter clip primitive if you wanted to clip before filtering is applied
06:48:23 <anthony> DS: What's the current behaviour of authoring tools and browsers
06:48:34 <anthony> ED: Opera clips before currently
06:48:45 <anthony> ... I think there are cases where it makes more sense to clip the output
06:48:59 <anthony> DS: Are we going to be at odds with authoring tools then?
06:49:17 <anthony> ... I'm concerned with what Inskape and Illustrator do
06:49:33 <shepazu> q-
06:49:33 <anthony> ... I think we have a better chance of getting Inkscape changed if need be
06:49:49 <anthony> ED: I think Opera will do what Batik is doing
06:50:09 <anthony> CM: Do you know if there are any tests in the test suite that test clipping order?
06:50:13 <anthony> ED: No not really
06:50:16 <anthony> ... currently making some
06:50:33 <anthony> CM: So have you decided which order it should be done?
06:50:37 <anthony> ED: Still up for discussion
06:50:44 <jwatt> JW: we could also add a feClip to clip a primitive output to an arbitrary clip path
06:50:52 <ed> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-offset-02-b.svg
06:50:59 <anthony> ED: This would be a test
06:51:27 <anthony> ED: I'm not sure it's fully correct
06:51:32 <anthony> ... this fails in Opera 10
06:51:46 <anthony> ... and FireFox it appears to give some red in the first case
06:52:12 <anthony> ... Jwatt if you want to take a shot at analysing and reviewing the test that would be great
06:53:11 <ed> http://dev.w3.org/SVG/docs/SVGTestSuite-howto.html
06:54:23 <anthony> ACTION: Jonathan to Review the filters-offset-02-b.svg test
06:54:23 <trackbot> Created ACTION-2632 - Review the filters-offset-02-b.svg test [on Jonathan Watt - due 2009-07-15].
06:56:00 <anthony> ACTION: Erik to Create test cases that test filter regions for a range of different filter primitives
06:56:00 <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].
06:56:24 <anthony> CM: So just going back to what Jwatt was saying before
06:56:45 <anthony> ... do we define that clipPath property doesn't apply to filter elements?
06:57:07 <anthony> ED: I think so. Filter primitive elements are not graphics elements
06:57:16 <anthony> ... so they don't apply.
06:57:34 <anthony> ... clipPath only applies to graphic and container elements
06:57:43 <anthony> CM: I wouldn't mind making it apply
06:57:54 <anthony> ... rather than introducing a new primitive
06:58:11 <anthony> DS: We couldn't really do that in 1.1
06:58:26 <anthony> ED: Probably not. Could do it in the filters module though
06:58:33 <anthony> ... I guess we could define it that way though
06:58:50 <anthony> CM: That would make it so we wouldn't have to insert these elements just to get clipping to apply
06:58:56 <anthony> ... to a filter
06:59:32 <anthony> Topic: ISSUE-2285
06:59:35 <anthony> ISSUE-2285?
06:59:35 <trackbot> ISSUE-2285 -- Resolving @primitiveUnits and z attribute discrepancies -- RAISED
06:59:35 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2285
06:59:58 <anthony> ED: There are z attributes on feSpotLight and fePointLight
07:00:11 <anthony> ... and both say they are dependent on the value of primitive units
07:00:23 <anthony> ... we don't really define any coordinate system for the z-axis
07:00:46 <anthony> ... I was wondering if the formula in the issue makes that much sense
07:01:00 <anthony> ... or if we should make it not depend on the primitive units
07:01:12 <anthony> CM: What's the coordinate system set up, or doesn't it matter?
07:01:32 <ed> http://www.w3.org/TR/SVG11/filters.html#feSpotLight
07:01:33 <anthony> ED: I think it doesn't really matter, just positive or negative
07:01:46 <anthony> CM: The Z points get put into the equations at some point
07:01:50 <anthony> ... so it doesn't really matter?
07:02:14 <anthony> ED: The points at Z are bit strange because it says at one point it depends on primitive units and in another
07:02:21 <anthony> ... place it says it doesn't
07:02:55 <anthony> CM: So you're pointing out the the points in Z don't depend on primitive units?
07:03:01 <anthony> ED: Not sure if that makes sense
07:03:21 <anthony> ... don't know why it would be good to have that square root equation
07:03:47 <anthony> CM: Probably you're going to pick a Z to get particular bright ness
07:04:56 <anthony> s/bright ness/brightness/
07:05:32 <anthony> ED: What's your suggested solution?
07:05:49 <anthony> ... unless there's some really good reason to have primitive units apply to this
07:05:53 <anthony> ... then they could be removed
07:06:07 <anthony> ... or the option is to correct the points at Z for feSpotLight
07:06:17 <anthony> ... to me it's a really arbitrary choice
07:06:30 <anthony> ... it's smaller change to add primitive units for Z
07:06:48 <anthony> CM: If it's not in the primitive units coordinate system what's it in?
07:06:53 <anthony> ED: User Space
07:08:42 <anthony> CM: I guess the X or Y thing needs to be fixed up
07:08:47 <anthony> ... regardless
07:09:27 <anthony> ED: I did implement this recently and made the choice of doing the squareroot calculation
07:10:27 <anthony> CM: It has to be in some coordinate system, so I guess using that equation seems reasonable
07:10:40 <anthony> ... to resolve the Z axis
07:10:58 <anthony> ... 1 unit along the Z axis is equal to equation
07:11:21 <anthony> ... and add the reference to primitive units to the points at Z as well
07:12:02 <anthony> ED: The squareroot equation is only applied to when you have primitive units set to ObjectBoundingBox
07:12:16 <anthony> CM: Maybe it's not reasonable then
07:12:38 <anthony> ... because you're using the are to get a single dimensional value
07:13:26 <anthony> ... what would be a good thing to do?
07:13:34 <anthony> ... average of X and Y?
07:14:06 <anthony> ... the only other alternative is to allow people to explicitly set the coordinate system
07:15:04 <anthony> ED: Could be difficult to do
07:15:32 <anthony> CM: Did you want to test different user agents?
07:15:47 <ed> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-light-01-f.svg
07:16:07 <anthony> ED: Don't know if that one is doing anything with primitive units
07:16:26 <anthony> ... could probably convert it to test the units
07:16:32 <anthony> ... shouldn't be too difficult
07:16:43 <anthony> CM: In this test the size of the X and Y coordinate systems are the same?
07:17:58 <anthony> AG: Doesn't sound like it would effect people greatly
07:18:06 <anthony> ... probably worth going for a simple solution
07:18:30 <anthony> ED: Average of X and Y or squareroot equation
07:20:11 <anthony> ... I will make some test cases and suggest some wording to appear in the spec
07:21:19 <anthony> ACTION: Erik to Create filter tests that test the Z units for feSpotLight and fePointLight and create some wording to address ISSUE-2285
07:21:19 <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].
07:21:42 <anthony> Topic: ISSUE-2286
07:21:45 <anthony> ISSUE-2286?
07:21:45 <trackbot> ISSUE-2286 -- Resolving relative values in @kernelUnitLength (number-optional-number) -- RAISED
07:21:45 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2286
07:22:05 <anthony> ED: There are a couple of attributes that use the optional number
07:22:11 <anthony> ... kernal unit length in filters
07:22:24 <anthony> ... how do you resolve the primitive units
07:22:32 <anthony> ... you have to expand the value to two values
07:22:40 <anthony> ... before running the filter chain
07:22:59 <anthony> ... given the choice of the two options in the issue
07:23:07 <anthony> ... I'd say expand the values first
07:23:43 <anthony> ... and then calculate the primitive unit scaling
07:23:55 <anthony> CM: I think that makes more sense
07:24:48 <anthony> ... Filter elements are the only one that use optional numbers?
07:25:00 <anthony> ED: There are a couple of places, but its similar for units
07:25:08 <anthony> CM: Do you know if we have tests?
07:25:16 <anthony> ED: We don't at the moment but I can provide some
07:26:33 <anthony> 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
07:26:33 <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].
07:27:19 <anthony> Topic: Test suite licence
07:27:20 <heycam> ACTION-2623?
07:27:20 <trackbot> ACTION-2623 -- Erik Dahlström to convert the test suites to use the 3-clause bsd licence -- due 2009-06-19 -- OPEN
07:27:20 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2623
07:27:35 <anthony> ED: Just wondering if the conversion script has been run
07:28:05 <anthony> AG: All done and checked in
07:28:31 <anthony> ED: Wondering if I should change the copyright part in each test?
07:28:42 <anthony> ... if I should change it what should I change it to
07:29:36 <anthony> CM: I guess it would be better to have it say something
07:29:45 <anthony> ... with the licence URL
07:30:28 <anthony> ED: Do you need to link each file to the licence URL?
07:30:47 <anthony> CM: Need to check if it's just one file at the top or in each individual file
07:31:31 <ed> http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html
07:32:32 <anthony> DS: I'll find out
07:32:42 <anthony> ... or if someone can summarise the issue
07:33:13 <anthony> ... Rigo is going on vacation very soon, so should be done right away
07:35:29 <anthony> Topic: Initial value of Colour interpolation filters
07:35:33 <heycam> http://www.w3.org/mid/20090706235532.GB3942@arc.mcc.id.au
07:36:25 <anthony> CM: Hans Schmucker wrote these perspective examples using color-interpolation-filters
07:36:41 <anthony> ... he was saying the initial value should be changed
07:37:11 <anthony> ED: It's probably easier if the initial value was sRGB from the start
07:37:37 <anthony> CM: Do you know of any other place where you'd want to have linearRGB as the default?
07:37:51 <anthony> ... gradients is something I can think of
07:40:03 <anthony> AG: Would like to find out from Chris why this is done
07:40:19 <anthony> DS: We should hold off on this issue
07:43:08 <anthony> Topic: animateTransform with matrix-decomposed like CSS
07:43:14 <anthony> ISSUE-2279?
07:43:14 <trackbot> ISSUE-2279 -- animateTransform with matrix-decomposed like CSS -- RAISED
07:43:14 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2279
07:43:26 <anthony> CM: picked this as one of the issues raised on SVG 2
07:43:36 <anthony> ... that we hadn't discussed yet
07:43:53 <anthony> ... in CSS Animations when you animate a transform property
07:44:12 <anthony> ... it does a decomposition of the transform
07:44:57 <anthony> ... and transforms between the components
07:45:35 <anthony> ... our animate transform for non-additive transforms will animate the specific items in the transform attribute
07:45:47 <anthony> ... there is no way to do this automatic composition in a particular order
07:46:22 <anthony> ... the issue is whether want to have this kind of animation or not
07:46:27 <anthony> ED: It might be
07:46:46 <anthony> ... You seem to be asking  if we could make a new type of transform as the default
07:46:51 <anthony> ... and that's not really possible
07:47:15 <anthony> ... if give it an unsupported value
07:47:39 <anthony> ... as long as the type is ignored by the tiny user agents then that's fine
07:47:44 <anthony> ... it is possible
07:47:48 <anthony> ... I take it back
07:48:13 <anthony> CM: Would this work for if you're animating between items where they don't match up exactly
07:49:48 <anthony> ... so does anyone remember what SVG it says about this?
07:50:11 <anthony> ... You have to give animateTransform a type
07:51:08 <anthony> ... could have animateTrasform type list
07:51:25 <anthony> ... and give it a list of transforms
07:53:48 <heycam> http://dev.w3.org/csswg/css3-2d-transforms/#animation
07:55:59 <anthony> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0310.html
07:58:17 <anthony> CM: Would certainly make it easier to unify the specs
07:59:13 <anthony> ... sounds like it's the stage where someone could propose some text to SVG 2
08:00:25 <anthony> ACTION: Cameron to Add animateTransformType="list" with behaviour that matches CSS animation
08:00:25 <trackbot> Created ACTION-2636 - Add animateTransformType="list" with behaviour that matches CSS animation [on Cameron McCormack - due 2009-07-15].
08:04:56 <Zakim> GA_SVGWG()2:30AM has ended
08:04:58 <Zakim> Attendees were 
08:05:15 <anthony> Zakim, bye
08:05:15 <Zakim> Zakim has left #svg
08:05:26 <anthony> RRSAgent, make minutes
08:05:26 <RRSAgent> I have made the request to generate http://www.w3.org/2009/07/08-svg-minutes.html anthony
08:06:02 <shepazu> I wasn't
08:08:01 <anthony> heycam, shepazu, should I cc the public list when I email Rigo?
08:08:22 <heycam> anthony, sure
08:08:38 <shepazu> fine by me
08:45:35 <eseidel> eseidel has joined #svg
08:47:44 <heycam> heycam has joined #svg
11:18:50 <karl> karl has joined #svg