IRC log of svg on 2011-01-19

Timestamps are in UTC.

19:30:29 [RRSAgent]: RRSAgent has joined #svg
19:30:29 [RRSAgent]: logging to http://www.w3.org/2011/01/19-svg-irc
19:30:31 [trackbot]: RRSAgent, make logs public
19:30:33 [trackbot]: Zakim, this will be GA_SVGWG
19:30:33 [Zakim]: I do not see a conference matching that name scheduled within the next hour, trackbot
19:30:34 [trackbot]: Meeting: SVG Working Group Teleconference
19:30:34 [trackbot]: Date: 19 January 2011
19:31:33 [shepazu]: Zakim, room for 7?
19:31:35 [Zakim]: ok, shepazu; conference Team_(svg)19:31Z scheduled with code 26632 (CONF2) for 60 minutes until 2031Z
19:33:39 [Zakim]: Team_(svg)19:31Z has now started
19:33:46 [Zakim]: +??P5
19:33:53 [ed]: Zakim: ??P5 is me
19:34:01 [ed]: Zakim, ??P5 is me
19:34:01 [Zakim]: +ed; got it
19:35:11 [Zakim]: +??P8
19:35:13 [Zakim]: +??P7
19:35:14 [heycam]: Zakim, ??P8 is me
19:35:15 [Zakim]: +heycam; got it
19:35:23 [anthony]: Zakim, ??P8 is me
19:35:23 [Zakim]: I already had ??P8 as heycam, anthony
19:35:47 [anthony]: Zakim, ??P7 is me
19:35:47 [Zakim]: +anthony; got it
19:35:51 [Zakim]: +Doug_Schepers
19:36:21 [ed]: agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0046.html
19:37:55 [ChrisL]: ChrisL has joined #svg
19:38:40 [ChrisL]: zakim, code?
19:38:40 [Zakim]: the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), ChrisL
19:39:32 [Zakim]: +ChrisL
19:41:19 [ed]: Zakim, pick a victim
19:41:19 [Zakim]: Not knowing who is chairing or who scribed recently, I propose Doug_Schepers
19:41:39 [shepazu]: scribe: shepazu
19:41:48 [shepazu]: scribenick: shepazu
19:42:04 [shepazu]: Topic: SVG 1.1 progress
19:42:24 [shepazu]: ed: saw an email sent out, no response from commenters
19:42:36 [shepazu]: ... what's the status on actions?
19:42:57 [ChrisL]: action-2921?
19:42:57 [trackbot]: ACTION-2921 -- Chris Lilley to bring the 1.2 changes for bidi and text anchor back to the 1.1 spec -- due 2010-12-16 -- OPEN
19:42:57 [trackbot]: http://www.w3.org/Graphics/SVG/WG/track/actions/2921
19:43:01 [shepazu]: ChrisL: Action-2921 on me is closed
19:43:34 [ChrisL]: close ACTION-2921
19:43:34 [trackbot]: ACTION-2921 Bring the 1.2 changes for bidi and text anchor back to the 1.1 spec closed
19:44:02 [ChrisL]: Opera is wrong, if the png images are correct
19:44:15 [shepazu]: ed: I think the PNG images in the spec are not correct on that one, will need to be changed
19:44:17 [shepazu]: ... Opera will need to update to the new bidi in the new build
19:44:38 [shepazu]: ed: I don't think the test is correct
19:44:44 [ChrisL]: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0020.html
19:44:47 [ed]: http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-text.png is incorrect
19:45:10 [shepazu]: ed: from left to right, it shoudl start with a dot
19:45:23 [ChrisL]: http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-text.svg
19:45:27 [shepazu]: ... the SVG Tiny spec has the correct image
19:45:29 [ChrisL]: looks correct in FF4
19:45:50 [shepazu]: ed: there are some differences in SVGT and SVG1.1
19:46:49 [shepazu]: ChrisL: in SVGT1.1 we didn't have tspan, and when we added SVGT1.2, we neglected to say it applied to tspan
19:47:14 [ed]: http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#TextAnchorProperty
19:47:28 [shepazu]: ... I've copied the text back from SVGT to SVG 1.1, does that mean the error got repeated?
19:47:52 [shepazu]: ed: no, it's the text-achor part I was concerned with, and that's okay
19:48:27 [ed]: http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-complex.png
19:48:37 [shepazu]: ed: the next image is also incorrect
19:49:09 [shepazu]: ChrisL: in 1.1, does it only apply to block level?
19:49:26 [ed]: http://www.w3.org/TR/SVGTiny12/examples/rtl-complex.png shows the expected result (but like i said i'm not 100% sure it's actually a correct 1.1 test)
19:49:29 [shepazu]: heycam: no, each of the chunks can be used to anchor
19:49:33 [ChrisL]: seems like text-anchor should apply only to text content block element
19:50:13 [shepazu]: ChrisL: this test only has the one anchor
19:51:03 [shepazu]: heycam: shouldn't the hebrew stuff go rtl?
19:51:11 [ChrisL]: direcion is set to rtl on the root svg and a tspan is set to ltr
19:51:11 [ChrisL]: http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-complex.svg
19:54:46 [shepazu]: ChrisL: this example is not sufficiently documented as to what it's trying to do
19:55:23 [shepazu]: ChrisL: maybe I should as the I18n folks, like r12a, to clarify this example
19:55:47 [shepazu]: heycam: example might be good if it had 2 versions of the file
19:56:09 [shepazu]: ... with different outcomes
19:56:49 [shepazu]: action: ChrisL to contact Ishida about bidi examples in the spec to simplify and clarify
19:56:49 [trackbot]: Created ACTION-2925 - Contact Ishida about bidi examples in the spec to simplify and clarify [on Chris Lilley - due 2011-01-26].
20:00:07 [shepazu]: Topic: Action-2816?
20:00:13 [shepazu]: Action-2816?
20:00:13 [trackbot]: ACTION-2816 -- Anthony Grasso to look into ISSUE-2339 and report back -- due 2010-07-13 -- OPEN
20:00:13 [trackbot]: http://www.w3.org/Graphics/SVG/WG/track/actions/2816
20:00:24 [shepazu]: ISSUE-2339?
20:00:24 [trackbot]: ISSUE-2339 -- Last Call Comment: definition of azimuth, elevation for feDistantLight -- open
20:00:24 [trackbot]: http://www.w3.org/Graphics/SVG/WG/track/issues/2339
20:00:57 [anthony]: http://lists.w3.org/Archives/Public/www-svg/2009Jul/0102.html
20:01:08 [shepazu]: anthony: this was Dr. Olaf's email
20:01:33 [anthony]: http://www.w3.org/TR/SVG11/filters.html#feDistantLightElement
20:01:52 [shepazu]: anthony: it regards this part of the spec
20:02:04 [anthony]: http://commons.wikimedia.org/wiki/File:Azimuth_%28PSF%29.svg
20:02:28 [shepazu]: anthony: this diagram is useful to understand it
20:03:09 [shepazu]: anthony: Dr. O points out that our spec is incorrect and a bit unclear
20:03:26 [anthony]: New wording: "Direction angle for the light source on the XY plane (clockwise), in degrees [from the X axis]"
20:04:15 [shepazu]: anthony: still figuring out what to write for elevation
20:04:17 [shepazu]: ... I'd like to discuss it with Eric
20:05:08 [shepazu]: heycam: I've been working on this lately, and without other implementations to reference, it's hard to figure out the degrees
20:05:39 [shepazu]: anthony: elevation might be a bit more of a headache
20:06:03 [anthony]: http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#feDiffuseLightingElement
20:06:20 [shepazu]: ... our formula for diffuse lighting is related our formula for distance lighting
20:06:58 [shepazu]: ... we need change the origin point of the angle for the elevation property
20:07:40 [shepazu]: heycam: is it simply not pointing in the right direction?
20:07:49 [shepazu]: anthony: yes, I think that's right
20:08:15 [shepazu]: heycam: I think I've run into this before for a script implementation
20:09:23 [shepazu]: anthony: I'll try to have this done by tomorrow
20:10:07 [anthony]: http://en.wikipedia.org/wiki/File:Azimuth_%28PSF%29_2.svg
20:10:15 [shepazu]: ... might be good to have a diagram
20:14:15 [shepazu]: ISSUE-2384?
20:14:15 [trackbot]: ISSUE-2384 -- Order of rx / ry computation for rounded rects -- pending review
20:14:15 [trackbot]: http://www.w3.org/Graphics/SVG/WG/track/issues/2384
20:14:43 [shepazu]: action: ChrisL to edit spec for ISSUE-2384
20:14:43 [trackbot]: Created ACTION-2926 - Edit spec for ISSUE-2384 [on Chris Lilley - due 2011-01-26].
20:15:32 [heycam]: ACTION-2926: this is my suggested wording change: http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0098.html
20:15:32 [trackbot]: ACTION-2926 Edit spec for ISSUE-2384 notes added
20:15:37 [ed]: http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg needs to be updated to align with that
20:15:48 [heycam]: ACTION-2926: but with this correction: http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0122.html
20:15:48 [trackbot]: ACTION-2926 Edit spec for ISSUE-2384 notes added
20:16:41 [shepazu]: Topic: test suite updates
20:16:46 [ed]: http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html
20:16:59 [shepazu]: ed: here is an updated implementation matrix
20:17:15 [shepazu]: ed: we're down to 43 tests that don't have 2 passes
20:18:05 [shepazu]: ChrisL: and I still have some checking to do
20:18:22 [shepazu]: shepazu: I'm going to see if Dirk could test WebKit
20:19:23 [shepazu]: heycam: I could do some of them
20:19:42 [jwatt]: jwatt has joined #svg
20:19:48 [Zakim]: -ChrisL
20:20:07 [ChrisL]: zakim, code?
20:20:07 [Zakim]: the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), ChrisL
20:20:07 [shepazu]: ChrisL: would it be possible to highlight the ones which don't have 2 passes?
20:20:28 [shepazu]: heycam: I can make that change to the script
20:20:29 [Zakim]: +ChrisL
20:21:20 [shepazu]: Topic: Test Suite issues
20:21:31 [tbah]: tbah has joined #svg
20:21:52 [heycam]: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0007.html
20:22:01 [ChrisL]: animate-elem-81-t
20:22:17 [shepazu]: heycam: animate-elem-81-t seems to be incorrect
20:23:07 [shepazu]: ... the text assumes some particular way transforms are accumulated, but it's not clearly specified in the spec, and is different to what SVGT1.2 does
20:23:36 [shepazu]: ... the specs don't say, but the tests have different assumptions
20:24:19 [shepazu]: .... Brian Birtles analyzed the differences between the SMIL tests and SVG tests, and concluded that the SVGT tests are correct
20:24:59 [shepazu]: ... I've found that there are 3 different ways that implementations handle accumulation
20:25:14 [shepazu]: ... for transform animations
20:25:16 [heycam]: http://people.mozilla.org/~cmccormack/tests/cumulative-transform.svg
20:25:32 [Zakim]: + +39.537.7.aaaa
20:25:39 [shepazu]: heycam: this test shows the 3 different ways, and what each browser does
20:26:24 [shepazu]: ... firefox and opera follow what SVGT does, and I think that's correct... webkit and batik are different (and incorrect)
20:28:11 [shepazu]: ed: I agree
20:28:27 [shepazu]: ChrisL: yes, and we should clarify this in the spec
20:29:23 [shepazu]: action: heycam to make proposed wording for transform animation accumulation, and make the tests
20:29:23 [trackbot]: Created ACTION-2927 - Make proposed wording for transform animation accumulation, and make the tests [on Cameron McCormack - due 2011-01-26].
20:30:31 [shepazu]: ed: does this effect other parts of this test?
20:30:38 [shepazu]: heycam: yes, I think so
20:30:55 [shepazu]: ed: the pass criteria on this test are not clear
20:31:35 [shepazu]: heycam: this would make abbra fail, but we would still have 2 passes
20:31:50 [shepazu]: ChrisL: I'm sure Abbra would change their implementation
20:32:02 [ed]: interact-pevents-04-t
20:32:14 [shepazu]: Topic: interact-pevents-04-t
20:32:15 [ed]: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0003.html
20:33:08 [shepazu]: ed: the reference image shows space characters, and space characters are not supposed to be visible per Unicode
20:33:37 [shepazu]: ChrisL: you've documented it well, we should clarify this in the spec
20:34:15 [shepazu]: ... if you provide a glyph, it should not be rendered, but the advance should be applied
20:35:20 [shepazu]: ... at least by default... you can have some special cases where the glyph can be rendered
20:35:43 [shepazu]: heycam: maybe that would be good to have in WOFF, a way to specify that
20:36:22 [shepazu]: shepazu: it would be handy for some proofing cases
20:36:46 [shepazu]: heycam: yeah, when the spaces stretch and so forth
20:37:53 [shepazu]: action: ed to add a note to the text chapter to describe what happens with space glyphs, and fix interact-pevents-04-t, and email the CSS mailing list proposing a way to control visibility of space glyphs
20:37:53 [trackbot]: Created ACTION-2928 - Add a note to the text chapter to describe what happens with space glyphs, and fix interact-pevents-04-t, and email the CSS mailing list proposing a way to control visibility of space glyphs [on Erik Dahlström - due 2011-01-26].
20:38:25 [shepazu]: Topic: conform-viewers-12-f
20:38:42 [shepazu]: ChrisL: I think this is incorrect
20:39:33 [shepazu]: http://www.w3.org/mid/1801756505.20110119200752@w3.org
20:39:36 [ChrisL]: And I think the test is wrong, because the data UIR scheme allows for a content-type but not a content-encoding; thus the test conflicts with
20:39:36 [ChrisL]: http://dev.w3.org/SVG/profiles/1.1F2/publish/conform.html#ConformingSVGServers
20:40:13 [shepazu]: ChrisL: this was a big point of contention
20:41:02 [shepazu]: ... a dataURI has a mime-type, but not content-encoding
20:41:17 [shepazu]: ... only way to change that would be to change dataURI spec
20:41:38 [ChrisL]: s/contention/contention in the IETF review of the svg media type/
20:42:11 [shepazu]: action: heycam to mark conform-viewers-02-f as unapproved
20:42:11 [trackbot]: Created ACTION-2929 - Mark conform-viewers-02-f as unapproved [on Cameron McCormack - due 2011-01-26].
20:42:48 [shepazu]: Topic: painting-marker-05
20:42:57 [ed]: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0002.html
20:46:11 [ChrisL]: abbra fails text-text-05-t.svg (may not do markers at all actually)
20:46:20 [ed]: http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/painting-marker-05-f.html
20:47:56 [shepazu]: heycam: I think overflow:auto at the moment is the same as visible, but to be consistent with CSS, dbaron and ROC would rather it would mean the same as hidden
20:48:32 [shepazu]: ChrisL: didn't we give a special value to the root?
20:49:01 [ed]: http://www.w3.org/TR/SVG11/masking.html#OverflowProperty
20:49:08 [shepazu]: ... implementations for symbols are different for for different browsers for the different quadrant
20:49:25 [shepazu]: s/the different quadrant/different quadrants/
20:49:37 [ChrisL]: in practice markers need to have overflow:visible if the marker goes outside the first quadrant
20:50:41 [shepazu]: heycam: overflow:auto in HTML content means there will never be content outside the box, which is different from SVG, where it means overflow:visible
20:51:14 [shepazu]: ed: strange to me that this is not the default
20:51:49 [shepazu]: ... in Opera, having it visible is less costly than hidden or auto
20:52:07 [ed]: s/or auto//
20:52:41 [shepazu]: heycam: maybe good to talk about at f2f, but need resolution on this test
20:53:20 [shepazu]: ed: IE9 gets this right, according to the reference
20:53:39 [shepazu]: heycam: FF can't be changed right away to pass this test
20:54:20 [shepazu]: Topic: text-align-07
20:54:57 [shepazu]: ed: should this test be skipped?
20:55:26 [ed]: http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.svg
20:55:40 [shepazu]: ChrisL: it's not clear to me that there's a requirement to draw the missing glyph
20:56:02 [shepazu]: ... sometimes it's a box, sometimes a hex code
20:56:16 [shepazu]: ... for arabic, should it be joined, all sorts of issues
20:56:25 [shepazu]: heycam: my opinion on this keeps changing
20:57:30 [shepazu]: heycam: I've heard different arguments for how this should be resolved
20:59:43 [shepazu]: heycam: FF doesn't treat the group baselines as the reference image does, but each group is self-consistent
21:00:05 [shepazu]: ... there's some XSL-FO behavior here
21:00:14 [shepazu]: ChrisL: yes, the dominant-baseline
21:00:35 [shepazu]: heycam: it wasn't clear to me what the requirements are from the SVG perspective
21:00:48 [Zakim]: -ChrisL
21:00:49 [shepazu]: ... and I'm also not sure which is preferred, which is more sensible
21:02:31 [shepazu]: action: heycam to research clarifications from i18n people and mozilla testers
21:02:32 [trackbot]: Created ACTION-2930 - Research clarifications from i18n people and mozilla testers [on Cameron McCormack - due 2011-01-26].
21:03:02 [shepazu]: ACTION-2930?
21:03:02 [trackbot]: ACTION-2930 -- Cameron McCormack to research clarifications from i18n people and mozilla testers -- due 2011-01-26 -- OPEN
21:03:02 [trackbot]: http://www.w3.org/Graphics/SVG/WG/track/actions/2930
21:05:00 [anthony]: http://www.w3.org/Graphics/SVG/WG/wiki/How_to_determine_dominant_baseline
21:05:04 [shepazu]: shepazu: I suggest we not include this test
21:05:38 [shepazu]: ... and clarify it in SVG 2
21:05:49 [shepazu]: trackbot, end telcon
21:05:49 [trackbot]: Zakim, list attendees
21:05:49 [Zakim]: As of this point the attendees have been ed, heycam, anthony, Doug_Schepers, ChrisL, +39.537.7.aaaa
21:05:50 [trackbot]: RRSAgent, please draft minutes
21:05:50 [RRSAgent]: I have made the request to generate http://www.w3.org/2011/01/19-svg-minutes.html trackbot
21:05:51 [trackbot]: RRSAgent, bye
21:05:51 [RRSAgent]: I see 6 open action items saved in http://www.w3.org/2011/01/19-svg-actions.rdf :
21:05:51 [RRSAgent]: ACTION: ChrisL to contact Ishida about bidi examples in the spec to simplify and clarify [1]
21:05:51 [RRSAgent]: recorded in http://www.w3.org/2011/01/19-svg-irc#T19-56-49
21:05:51 [RRSAgent]: ACTION: ChrisL to edit spec for ISSUE-2384 [2]
21:05:51 [RRSAgent]: recorded in http://www.w3.org/2011/01/19-svg-irc#T20-14-43
21:05:51 [RRSAgent]: ACTION: heycam to make proposed wording for transform animation accumulation, and make the tests [3]
21:05:51 [RRSAgent]: recorded in http://www.w3.org/2011/01/19-svg-irc#T20-29-23
21:05:51 [RRSAgent]: ACTION: ed to add a note to the text chapter to describe what happens with space glyphs, and fix interact-pevents-04-t, and email the CSS mailing list proposing a way to control visibility of space glyphs [4]
21:05:51 [RRSAgent]: recorded in http://www.w3.org/2011/01/19-svg-irc#T20-37-53
21:05:51 [RRSAgent]: ACTION: heycam to mark conform-viewers-02-f as unapproved [5]
21:05:51 [RRSAgent]: recorded in http://www.w3.org/2011/01/19-svg-irc#T20-42-11
21:05:51 [RRSAgent]: ACTION: heycam to research clarifications from i18n people and mozilla testers [6]
21:05:51 [RRSAgent]: recorded in http://www.w3.org/2011/01/19-svg-irc#T21-02-31
21:05:51 [Zakim]: - +39.537.7.aaaa
21:05:57 [Zakim]: -ed
21:05:59 [Zakim]: -heycam
21:06:03 [Zakim]: -Doug_Schepers
21:06:04 [Zakim]: -anthony
21:06:05 [Zakim]: Team_(svg)19:31Z has ended
21:06:07 [Zakim]: Attendees were ed, heycam, anthony, Doug_Schepers, ChrisL, +39.537.7.aaaa