SVG Working Group Teleconference -- 19 Jan 2011

<trackbot> Date: 19 January 2011

<ed> Zakim: ??P5 is me

<scribe> scribe: shepazu

<scribe> scribenick: shepazu

SVG 1.1 progress

ed: saw an email sent out, no response from commenters
... what's the status on actions?

<ChrisL> action-2921?

<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

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2921

ChrisL: Action-2921 on me is closed

<ChrisL> close ACTION-2921

<trackbot> ACTION-2921 Bring the 1.2 changes for bidi and text anchor back to the 1.1 spec closed

<ChrisL> Opera is wrong, if the png images are correct

ed: I think the PNG images in the spec are not correct on that one, will need to be changed
... Opera will need to update to the new bidi in the new build
... I don't think the test is correct

<ChrisL> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0020.html

<ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-text.png is incorrect

ed: from left to right, it shoudl start with a dot

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-text.svg

ed: the SVG Tiny spec has the correct image

<ChrisL> looks correct in FF4

ed: there are some differences in SVGT and SVG1.1

ChrisL: in SVGT1.1 we didn't have tspan, and when we added SVGT1.2, we neglected to say it applied to tspan

<ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#TextAnchorProperty

ChrisL: I've copied the text back from SVGT to SVG 1.1, does that mean the error got repeated?

ed: no, it's the text-achor part I was concerned with, and that's okay

<ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-complex.png

ed: the next image is also incorrect

ChrisL: in 1.1, does it only apply to block level?

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

heycam: no, each of the chunks can be used to anchor

<ChrisL> seems like text-anchor should apply only to text content block element

ChrisL: this test only has the one anchor

heycam: shouldn't the hebrew stuff go rtl?

<ChrisL> direcion is set to rtl on the root svg and a tspan is set to ltr

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-complex.svg

ChrisL: this example is not sufficiently documented as to what it's trying to do
... maybe I should as the I18n folks, like r12a, to clarify this example

heycam: example might be good if it had 2 versions of the file
... with different outcomes

<scribe> ACTION: ChrisL to contact Ishida about bidi examples in the spec to simplify and clarify [recorded in http://www.w3.org/2011/01/19-svg-minutes.html#action01]

<trackbot> Created ACTION-2925 - Contact Ishida about bidi examples in the spec to simplify and clarify [on Chris Lilley - due 2011-01-26].

Action-2816?

<trackbot> ACTION-2816 -- Anthony Grasso to look into ISSUE-2339 and report back -- due 2010-07-13 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2816

ISSUE-2339?

<trackbot> ISSUE-2339 -- Last Call Comment: definition of azimuth, elevation for feDistantLight -- open

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2339

<anthony> http://lists.w3.org/Archives/Public/www-svg/2009Jul/0102.html

anthony: this was Dr. Olaf's email

<anthony> http://www.w3.org/TR/SVG11/filters.html#feDistantLightElement

anthony: it regards this part of the spec

<anthony> http://commons.wikimedia.org/wiki/File:Azimuth_%28PSF%29.svg

anthony: this diagram is useful to understand it
... Dr. O points out that our spec is incorrect and a bit unclear

<anthony> New wording: "Direction angle for the light source on the XY plane (clockwise), in degrees [from the X axis]"

anthony: still figuring out what to write for elevation
... I'd like to discuss it with Eric

heycam: I've been working on this lately, and without other implementations to reference, it's hard to figure out the degrees

anthony: elevation might be a bit more of a headache

<anthony> http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#feDiffuseLightingElement

anthony: our formula for diffuse lighting is related our formula for distance lighting
... we need change the origin point of the angle for the elevation property

heycam: is it simply not pointing in the right direction?

anthony: yes, I think that's right

heycam: I think I've run into this before for a script implementation

anthony: I'll try to have this done by tomorrow

<anthony> http://en.wikipedia.org/wiki/File:Azimuth_%28PSF%29_2.svg

anthony: might be good to have a diagram

ISSUE-2384?

<trackbot> ISSUE-2384 -- Order of rx / ry computation for rounded rects -- pending review

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2384

<scribe> ACTION: ChrisL to edit spec for ISSUE-2384 [recorded in http://www.w3.org/2011/01/19-svg-minutes.html#action02]

<trackbot> Created ACTION-2926 - Edit spec for ISSUE-2384 [on Chris Lilley - due 2011-01-26].

<heycam> ACTION-2926: this is my suggested wording change: http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0098.html

<trackbot> ACTION-2926 Edit spec for ISSUE-2384 notes added

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg needs to be updated to align with that

<heycam> ACTION-2926: but with this correction: http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0122.html

<trackbot> ACTION-2926 Edit spec for ISSUE-2384 notes added

test suite updates

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html

ed: here is an updated implementation matrix
... we're down to 43 tests that don't have 2 passes

ChrisL: and I still have some checking to do

shepazu: I'm going to see if Dirk could test WebKit

heycam: I could do some of them

ChrisL: would it be possible to highlight the ones which don't have 2 passes?

heycam: I can make that change to the script

Test Suite issues

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0007.html

<ChrisL> animate-elem-81-t

heycam: animate-elem-81-t seems to be incorrect
... 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
... the specs don't say, but the tests have different assumptions
... Brian Birtles analyzed the differences between the SMIL tests and SVG tests, and concluded that the SVGT tests are correct
... I've found that there are 3 different ways that implementations handle accumulation
... for transform animations

<heycam> http://people.mozilla.org/~cmccormack/tests/cumulative-transform.svg

heycam: this test shows the 3 different ways, and what each browser does
... firefox and opera follow what SVGT does, and I think that's correct... webkit and batik are different (and incorrect)

ed: I agree

ChrisL: yes, and we should clarify this in the spec

<scribe> ACTION: heycam to make proposed wording for transform animation accumulation, and make the tests [recorded in http://www.w3.org/2011/01/19-svg-minutes.html#action03]

<trackbot> Created ACTION-2927 - Make proposed wording for transform animation accumulation, and make the tests [on Cameron McCormack - due 2011-01-26].

ed: does this effect other parts of this test?

heycam: yes, I think so

ed: the pass criteria on this test are not clear

heycam: this would make abbra fail, but we would still have 2 passes

ChrisL: I'm sure Abbra would change their implementation

<ed> interact-pevents-04-t

interact-pevents-04-t

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0003.html

ed: the reference image shows space characters, and space characters are not supposed to be visible per Unicode

ChrisL: you've documented it well, we should clarify this in the spec
... if you provide a glyph, it should not be rendered, but the advance should be applied
... at least by default... you can have some special cases where the glyph can be rendered

heycam: maybe that would be good to have in WOFF, a way to specify that

shepazu: it would be handy for some proofing cases

heycam: yeah, when the spaces stretch and so forth

<scribe> 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 [recorded in http://www.w3.org/2011/01/19-svg-minutes.html#action04]

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

conform-viewers-12-f

ChrisL: I think this is incorrect

http://www.w3.org/mid/1801756505.20110119200752@w3.org

<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

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/publish/conform.html#ConformingSVGServers

ChrisL: this was a big point of contention in the IETF review of the svg media type
... a dataURI has a mime-type, but not content-encoding
... only way to change that would be to change dataURI spec

<scribe> ACTION: heycam to mark conform-viewers-02-f as unapproved [recorded in http://www.w3.org/2011/01/19-svg-minutes.html#action05]

<trackbot> Created ACTION-2929 - Mark conform-viewers-02-f as unapproved [on Cameron McCormack - due 2011-01-26].

painting-marker-05

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0002.html

<ChrisL> abbra fails text-text-05-t.svg (may not do markers at all actually)

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/painting-marker-05-f.html

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

ChrisL: didn't we give a special value to the root?

<ed> http://www.w3.org/TR/SVG11/masking.html#OverflowProperty

ChrisL: implementations for symbols are different for for different browsers for different quadrants

<ChrisL> in practice markers need to have overflow:visible if the marker goes outside the first quadrant

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

ed: strange to me that this is not the default
... in Opera, having it visible is less costly than hidden

heycam: maybe good to talk about at f2f, but need resolution on this test

ed: IE9 gets this right, according to the reference

heycam: FF can't be changed right away to pass this test

text-align-07

ed: should this test be skipped?

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.svg

ChrisL: it's not clear to me that there's a requirement to draw the missing glyph
... sometimes it's a box, sometimes a hex code
... for arabic, should it be joined, all sorts of issues

heycam: my opinion on this keeps changing
... I've heard different arguments for how this should be resolved
... FF doesn't treat the group baselines as the reference image does, but each group is self-consistent
... there's some XSL-FO behavior here

ChrisL: yes, the dominant-baseline

heycam: it wasn't clear to me what the requirements are from the SVG perspective
... and I'm also not sure which is preferred, which is more sensible

<scribe> ACTION: heycam to research clarifications from i18n people and mozilla testers [recorded in http://www.w3.org/2011/01/19-svg-minutes.html#action06]

<trackbot> Created ACTION-2930 - Research clarifications from i18n people and mozilla testers [on Cameron McCormack - due 2011-01-26].

ACTION-2930?

<trackbot> ACTION-2930 -- Cameron McCormack to research clarifications from i18n people and mozilla testers -- due 2011-01-26 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2930

<anthony> http://www.w3.org/Graphics/SVG/WG/wiki/How_to_determine_dominant_baseline

shepazu: I suggest we not include this test
... and clarify it in SVG 2

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

19 Jan 2011

Attendees

Contents