19:30:47 <RRSAgent> RRSAgent has joined #svg
19:30:47 <RRSAgent> logging to http://www.w3.org/2008/12/15-svg-irc
19:30:49 <trackbot> RRSAgent, make logs public
19:30:51 <trackbot> Zakim, this will be GA_SVGWG
19:30:51 <Zakim> ok, trackbot; I see GA_SVGWG()2:30PM scheduled to start now
19:30:52 <trackbot> Meeting: SVG Working Group Teleconference
19:30:52 <trackbot> Date: 15 December 2008
19:31:19 <Zakim> GA_SVGWG()2:30PM has now started
19:31:26 <Zakim> +??P1
19:31:52 <shepazu> Zakim, +??P1 is me
19:31:52 <Zakim> sorry, shepazu, I do not recognize a party named '+??P1'
19:32:02 <shepazu> Zakim, ??P1 is me
19:32:02 <Zakim> +shepazu; got it
19:32:09 <shepazu> that's annoying
19:32:19 <Zakim> +[IPcaller]
19:32:37 <ed> Zakim, [IP is me
19:32:37 <Zakim> +ed; got it
19:33:37 <Zakim> +??P3
19:33:39 <heycam> Zakim, ??P3 is me
19:33:39 <Zakim> +heycam; got it
19:33:52 <Zakim> +??P4
19:34:03 <anthony> Zakim, ??P4 is me
19:34:03 <Zakim> +anthony; got it
19:34:32 <ed> Zakim, who's here?
19:34:32 <Zakim> On the phone I see shepazu, ed, heycam, anthony
19:34:33 <Zakim> On IRC I see RRSAgent, Zakim, ed, heycam, shepazu, anthony, trackbot, ed_work
19:36:53 <shepazu> http://www.w3.org/2002/09/wbs/19480/SydneyF2F2009/
19:37:02 <ed> scribeNick: ed
19:37:15 <ed> Topic: Sydney f2f
19:37:46 <shepazu> http://www.w3.org/2002/09/wbs/19480/SydneyF2F2009/results
19:40:06 <ed> AG: please register if you're coming
19:40:22 <ed> ED: location?
19:40:23 <Zakim> +ChrisL
19:40:26 <ed> AG: probably manly
19:40:52 <ChrisL> ChrisL has joined #svg
19:41:11 <ChrisL> zakim, who is here?
19:41:11 <Zakim> On the phone I see shepazu, ed, heycam, anthony, ChrisL
19:41:12 <Zakim> On IRC I see ChrisL, RRSAgent, Zakim, ed, heycam, shepazu, anthony, trackbot, ed_work
19:41:30 <ed> Topic: svg 1.1 errata
19:42:16 <anthony> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#propogation-of-rotation-text
19:43:35 <ed> http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/errata/errata.xml.diff?r1=1.16&r2=1.17&f=h
19:44:54 <ed> CM: some small things
19:45:09 <ChrisL> CM: </svg>;
19:45:09 <ChrisL>  is wrong
19:46:09 <ed> CL: the included file seems fine, but the inline example is wrong
19:46:16 <ChrisL> trailing semicolon is not in the source that is included; must be in the arrata
19:46:21 <ChrisL> s/arr/err/
19:46:50 <ChrisL> zakim, mute me
19:46:50 <Zakim> ChrisL should now be muted
19:47:35 <ed> ED: is it correct that it maps rotate to characters and not to glyphs?
19:47:36 <ChrisL> zakim, unmute me
19:47:36 <Zakim> ChrisL should no longer be muted
19:47:46 <ed> AG: yes
19:48:29 <ChrisL> zakim, mute me
19:48:29 <Zakim> ChrisL should now be muted
19:48:53 <ed> CL: the spec tells you what to do for those cases, important for ligatures for example, you skip values if you do a ligature
19:49:31 <ChrisL> particularly important to avoid off-by-one errors with optional ligatures
19:49:45 <heycam> propogation -> propagation
19:50:14 <heycam> the links to the rotate attribute should have single quotes around them (like the element links)
19:50:35 <heycam> most of the links have an unwanted trailing space within the link
19:50:56 <ChrisL> yup, thats right. does not affect tiny
19:51:14 <heycam> ED: is this in tiny?
19:51:28 <heycam> AG: no, tiny doesn't have positioning attributes on tspans etc.
19:51:37 <heycam> Scribe: Cameron
19:51:40 <heycam> ScribeNick: heycam
19:51:59 <heycam> ED: is there any example with both rotate and x/y positioning at the same time?
19:52:00 <heycam> AG: no
19:52:12 <heycam> ED: i'm wondering if it's defined in what order they're applied, if it makes any difference
19:52:26 <heycam> CM: would it make any difference?
19:52:47 <heycam> ED: wouldn't think so
19:53:15 <heycam> "the the (orange)" -> "the (orange)"
19:53:25 <heycam> ED: it says "supplemental rotation", so it seems to be pretty clear
19:54:34 <heycam> ED: might be easier to read if the paragraph describing the rotations is split into a list
19:54:38 <heycam> CM: maybe a list item per element
19:55:25 <heycam> AG: ok should be easy
19:56:01 <heycam> ED: optionally you could be the same text inside the test, as the test description
19:56:44 <heycam> ED: is it informative or normative?
19:56:47 <heycam> AG: informative
19:57:00 <heycam> ED: probably should note it as informative
19:57:30 <ChrisL> zakim, unmute me
19:57:30 <Zakim> ChrisL should no longer be muted
19:57:40 <heycam> ED: there might some generic statement that says that all examples are informative
19:57:47 <ChrisL> zakim, mute me
19:57:47 <Zakim> ChrisL should now be muted
19:59:50 <ChrisL> +1
20:00:10 <heycam> ED: should we move it to proposed?
20:01:20 <ChrisL> zakim, who is noisy?
20:01:30 <Zakim> ChrisL, listening for 10 seconds I heard sound from the following: shepazu (89%)
20:03:08 <heycam> CM: do you have an svg version of the rotation diagram?
20:03:11 <heycam> AG: no i might make one
20:03:22 <heycam> ED: pending these changes we can move it to proposed
20:03:45 <heycam> AG: batik and opera do the same thing, which is not propagating the rotation into tspans
20:03:59 <heycam> AG: and not onto the text after a child tspan
20:04:12 <heycam> AG: in example 5, the last word "rotation" doesn't have any characters rotated in batik/opera
20:05:00 <heycam> ED: for us it'd be nice so we don't have to do two different things for rotation [since it's different in tiny]
20:05:07 <heycam> ED: i'd like to hear jwatt's comments
20:05:36 <heycam> ED: have you tested firefox?
20:05:41 <heycam> AG: yes they don't rotate any of the characters
20:06:29 <heycam> CM: what made us choose to do it this way?
20:06:51 <heycam> AG: in tiny, if there are fewer rotations than characters, it doesn't say what to do if there's a tspan
20:07:03 <heycam> AG: so the erratum makes 1.1 align with tiny
20:07:33 <heycam> CL: aligns and extends
20:07:37 <heycam> CM: it was undefined in 1.1?
20:07:39 <heycam> AG: yes
20:08:12 <ChrisL> zakim, unmute me
20:08:12 <Zakim> ChrisL should no longer be muted
20:08:15 <heycam> ED: it's not interoperable at the moment, so hopefully this will make it usuable
20:08:28 <heycam> ED: don't know if we had many 1.2T tests for text rotation
20:08:43 <heycam> CL: it'd be a good test for 1.1e2
20:09:06 <heycam> CL: more likely to get fixed in implementations if there are tests
20:09:19 <heycam> CM: are there tests associated with this erratum?
20:09:38 <heycam> AG: no but i could take the tspan05 example and turn it into a test
20:10:05 <heycam> AG: change the text colour to green, with expected rotation characters in red underneath
20:10:43 <heycam> ED: should probably make all errata tests into proper test suite tests for a release later
20:11:55 <heycam> Topic: clip path erratum
20:12:02 <heycam> ED: more feedback from thomas?
20:12:33 <heycam> DS: he is arguing from the point of view of implementing, but to me it is more important how useful the feature is
20:12:48 <heycam> DS: and it's not a burden to implement it the way we've described
20:13:09 <heycam> DS: he argues that it's hacky/ugly, but i don't think he's substantiated that
20:13:31 <ChrisL> I agree with Doug
20:14:00 <heycam> ED: i'd agree that it would put a burden on implementations to change things, but it's not a big burden
20:14:23 <heycam> DS: i mean an undue burden.  any change needs effort.
20:14:39 <heycam> DS: he seems to be claiming that batik is doing it a certain way, turning clip paths into masks
20:15:19 <ChrisL> zakim, unmute me
20:15:19 <Zakim> ChrisL was not muted, ChrisL
20:15:27 <shepazu> http://lists.w3.org/Archives/Public/www-svg/2008Dec/0041.html
20:15:29 <heycam> CM: i think that was part of his argument that clip paths are more like pixel operations
20:16:53 <heycam> DS: i don't see a conflict with tying visibility to clipping, but he does
20:17:28 <heycam> CL: i think it's consistent to tie the visible* values to clipping
20:17:30 <heycam> ED: i'd agree
20:17:43 <heycam> ED: it would not be a good idea to introduce more pointer-events values
20:18:15 <heycam> ED: introducing new elements could be an option in the future
20:19:13 <heycam> DS: i think it's worth the little bit of work for implementors to do it this way
20:19:29 <heycam> CL: it's unspecified at the moment, some implementations have to change, we think we've changed it the right way
20:20:18 <heycam> DS: if we change this, how hard would it be to change the behaviour in batik?
20:21:49 <heycam> CM: i think not hard, thomas has created a patch that unconditionally (irrespective of pointer-events) clips events
20:22:50 <heycam> ED: so the only thing missing from batik would be treating the visible* values differently
20:22:54 <heycam> ED: same change for firefox
20:23:08 <Zakim> -shepazu
20:23:20 <heycam> DS: and safari would have to change to clip by default, and doesn't clip when pointer-events has particular values
20:23:43 <heycam> CL: has safari implemented it differently, or not at all?
20:24:15 <heycam> ED: they do clipping, but perhaps the same as batik currently
20:24:19 <shepazu> ran out of skype credit.... will be back in a moment
20:24:49 <heycam> ED: i don't think it's a bad change
20:25:03 <heycam> CL: i think we should move it to proposed
20:25:33 <heycam> https://issues.apache.org/bugzilla/show_bug.cgi?id=46289
20:26:04 <heycam> RESOLUTION: Move this clip path events erratum to proposed
20:28:23 <Zakim> +??P6
20:28:30 <heycam> Topic: 1.1 test suite bug
20:28:44 <ChrisL> zakim, ??P6 is shepazu
20:28:44 <Zakim> +shepazu; got it
20:31:22 <heycam> Topic: name of SVG Tiny 1.2
20:32:55 <ChrisL> It has been suggested that Tiny 1.2 should be called Core 1.2
20:34:08 <heycam> DS: an issue with the name of the SVG Tiny 1.2 spec has come up
20:34:35 <heycam> DS: it's been suggested that we name it SVG 1.2 Core, it becoming the core language that 1.2 modules go on top of
20:34:42 <heycam> s/becoming/being/
20:34:55 <heycam> CL: we've already said it's the core of the language, calling it Core 1.2 is reasonably consistent
20:35:02 <heycam> CL: and when we come up with Core 2.0 it's consistent
20:35:11 <heycam> CL: otoh, the name SVGT has a bit of traction
20:35:23 <heycam> CL: getting rid of that term would be a problem
20:35:41 <heycam> DS: we'd have to hear from the two main mobile vendors
20:36:01 <heycam> AG: i agree with chris, can see both sides of the coin
20:36:12 <heycam> DS: i'm the same way, fairly ambivalent
20:36:46 <heycam> DS: i wonder if people might look at SVG Core and say "oh, there's something new" rather than as svg tiny
20:36:55 <heycam> DS: people might think svg tiny is old news
20:37:19 <heycam> DS: otoh, calling it Core sends a certain message to the browser vendors that we think this is the core of the language, which some of them have objected to in the past
20:37:33 <heycam> AG: be good to get feedback from mobile and desktop implementors
20:38:38 <heycam> ED: practically, doing the name change would mean going through the spec and changing all instances of the name
20:38:42 <heycam> ED: other specs that reference it?
20:38:55 <heycam> DS: might create confusion in the marketplace about whether svg is implemented/used
20:39:10 <heycam> DS: i think if this issue had come up earlier it might've been more feasible
20:39:32 <heycam> DS: we could ask ikivo/bitflash what they think about it
20:40:12 <heycam> CM: they probably have promotional material already published with the current name
20:40:31 <heycam> DS: i'm inclined to say that unless we get buy-in from bitflash/ikivo, we keep the name as is
20:40:52 <heycam> DS: an appropriate time to have done this might've been when we went back to LC
20:41:43 <heycam> ED: we'd have to decide before going to rec.  there are 3 more days of AC review?
20:41:53 <heycam> ED: after those days what happens?
20:42:08 <heycam> DS: planning on publishing on friday
20:42:19 <heycam> DS: i'll email bitflash/ikivo
20:42:33 <heycam> ED: my opinion would be that it would cause confusion rather than unity or anything
20:43:22 <heycam> Topic: SVG 1.1 test suite bug
20:43:25 <heycam> ED: we got a bug report
20:43:30 <heycam> ED: are we using the bugzilla?
20:43:45 <heycam> DS: if people are comfortable raising bugs that way, then we should keep it
20:43:56 <heycam> CL: preferable to people adding it to our tracker
20:44:54 <heycam> ED: this particular test case does have an incorrect reference image, i think
20:45:10 <heycam> ED: i don't think it's news; we probably have it in the old tracker, along with other test suite bugs
20:45:24 <heycam> ED: we should track it in the new tracker and fix it as part of releasing the 1.1e2 spec
20:45:49 <heycam> ED: having someone respond is a good idea
20:45:51 <heycam> CL: i'll respond
20:46:10 <heycam> ACTION: Chris to respond to the bugzilla bug on the incorrect reference image
20:46:10 <trackbot> Created ACTION-2381 - Respond to the bugzilla bug on the incorrect reference image [on Chris Lilley - due 2008-12-22].
20:46:19 <heycam> CL: why is the reference image incorrect?  what makes it wrong?
20:46:27 <heycam> ED: not sure exactly, the link he gives (blow-by-blow) is correct
20:46:28 <ChrisL> ok so why is the reference image wrong here?
20:46:37 <ChrisL> batik uses a series of box blurs?
20:46:39 <heycam> ED: i'd guess that batik just generated it incorrectly or that it was an incorrect patch file
20:46:43 <ChrisL> could be a buggy patch file
20:46:50 <heycam> CL: i'll look into that
20:47:33 <heycam> ED: until we have the 1.1 test suite moved over, it's difficult to do the fixes
20:47:39 <heycam> ED: any status update on that?
20:48:43 <heycam> DS: we decided not to do it, since we need to change the tests anyway
20:48:46 <heycam> DS: so revision numbers didn't matter
20:48:51 <ed> http://www.w3.org/Graphics/SVG/WG/track/actions/2373 ?
20:49:13 <heycam> CM: didn't we say that we should do it to keep the cvs logs?
20:49:26 <heycam> CL: i'd imagine the best thing would be to port the 1.2T copies
20:49:34 <heycam> CL: using the 1.1 <-> 1.2T test name correspondence table
20:49:52 <heycam> CL: checking them in with cvs revision 1.1 files
20:49:59 <heycam> CL: we shouldn't lose the fixes we made in 1.2T
20:50:17 <heycam> ED: i have a feeling most of those fixes were for xml:id and not much else
20:50:22 <heycam> ED: e.g. tiny things that weren't in 1.1
20:50:41 <heycam> ED: i could be wrong but that's my feel of it
20:51:03 <heycam> ED: things like changing percentages to [0,1] ranges for gradients, minor things like that
20:51:21 <heycam> ED: might be a good idea to check
20:51:35 <heycam> ED: since we have that name correspondence table, the files could be diffed to see if there are major changes
20:51:41 <heycam> ED: shouldn't take too long
20:51:44 <ChrisL> yes i agree a pairwise diff would eb good looking for non-obvious changes
20:52:29 <heycam> ED: for the moving over would we create new files and lose the history?
20:53:46 <heycam> ED: i don't know if it's hard to copy them over without the history then
20:54:05 <heycam> CL: are we copying 1.1?  or 1.2T and changing them back?
20:54:18 <heycam> ED: i'd like to take the 1.2T ones that have appropriate changes from the 1.1 versions
20:54:56 <ed> s/1.2T/1.1 and then diff the 1.2T ones against these/
20:56:03 <heycam> ACTION: Erik to move the 1.1 tests to public cvs, checking diffs against the corresponding 1.2T tests
20:56:03 <trackbot> Created ACTION-2382 - Move the 1.1 tests to public cvs, checking diffs against the corresponding 1.2T tests [on Erik Dahlström - due 2008-12-22].
20:56:17 <heycam> AG: are we using the new test template when we move them over?
20:56:25 <heycam> ED: that'd be a followup thing i guess
20:57:07 <heycam> CL: i'd copy and include in the commit log a pointer to the old file
20:58:34 <heycam> ACTION: Cameron to summarise last telcon's discussions on svg-in-html and reply to the existing thread
20:58:34 <trackbot> Created ACTION-2383 - Summarise last telcon's discussions on svg-in-html and reply to the existing thread [on Cameron McCormack - due 2008-12-22].
21:00:43 <Zakim> -shepazu
21:00:44 <Zakim> -heycam
21:00:45 <Zakim> -anthony
21:00:46 <Zakim> -ChrisL
21:00:46 <Zakim> -ed
21:00:48 <Zakim> GA_SVGWG()2:30PM has ended
21:00:49 <Zakim> Attendees were shepazu, [IPcaller], ed, heycam, anthony, ChrisL
21:01:28 <heycam> RRSAgent, make minutes
21:01:28 <RRSAgent> I have made the request to generate http://www.w3.org/2008/12/15-svg-minutes.html heycam
22:00:44 <heycam> heycam has joined #svg
22:43:19 <shepazu> shepazu has joined #svg
23:29:23 <Zakim> Zakim has left #svg