- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 19 Jan 2011 16:08:13 -0500
- To: www-svg <www-svg@w3.org>
HTML version:
http://www.w3.org/2011/01/19-svg-minutes.html
Text version:
SVG Working Group Teleconference
19 Jan 2011
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0046.html
See also: [3]IRC log
[3] http://www.w3.org/2011/01/19-svg-irc
Attendees
Present
ed, heycam, anthony, Doug_Schepers, ChrisL, +39.537.7.aaaa
Regrets
Chair
SV_MEETING_CHAIR
Scribe
shepazu
Contents
* [4]Topics
1. [5]SVG 1.1 progress
2. [6]Action-2816?
3. [7]test suite updates
4. [8]Test Suite issues
5. [9]interact-pevents-04-t
6. [10]conform-viewers-12-f
7. [11]painting-marker-05
8. [12]text-align-07
* [13]Summary of Action Items
_________________________________________________________
<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> [14]http://www.w3.org/Graphics/SVG/WG/track/actions/2921
[14] 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>
[15]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/002
0.html
[15]
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0020.html
<ed>
[16]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-tex
t.png is incorrect
[16]
http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-text.png
ed: from left to right, it shoudl start with a dot
<ChrisL>
[17]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-tex
t.svg
[17]
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>
[18]http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#TextAncho
rProperty
[18]
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>
[19]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-com
plex.png
[19]
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> [20]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)
[20] http://www.w3.org/TR/SVGTiny12/examples/rtl-complex.png
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>
[21]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-com
plex.svg
[21]
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
[22]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?
Action-2816?
<trackbot> ACTION-2816 -- Anthony Grasso to look into ISSUE-2339 and
report back -- due 2010-07-13 -- OPEN
<trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/actions/2816
[23] 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> [24]http://www.w3.org/Graphics/SVG/WG/track/issues/2339
[24] http://www.w3.org/Graphics/SVG/WG/track/issues/2339
<anthony>
[25]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0102.html
[25] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0102.html
anthony: this was Dr. Olaf's email
<anthony>
[26]http://www.w3.org/TR/SVG11/filters.html#feDistantLightElement
[26] http://www.w3.org/TR/SVG11/filters.html#feDistantLightElement
anthony: it regards this part of the spec
<anthony>
[27]http://commons.wikimedia.org/wiki/File:Azimuth_%28PSF%29.svg
[27] 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>
[28]http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#feDi
ffuseLightingElement
[28]
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>
[29]http://en.wikipedia.org/wiki/File:Azimuth_%28PSF%29_2.svg
[29] 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> [30]http://www.w3.org/Graphics/SVG/WG/track/issues/2384
[30] http://www.w3.org/Graphics/SVG/WG/track/issues/2384
<scribe> ACTION: ChrisL to edit spec for ISSUE-2384 [recorded in
[31]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:
[32]http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/009
8.html
[32]
http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0098.html
<trackbot> ACTION-2926 Edit spec for ISSUE-2384 notes added
<ed>
[33]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.s
vg needs to be updated to align with that
[33]
http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg
<heycam> ACTION-2926: but with this correction:
[34]http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/012
2.html
[34]
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>
[35]http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_
matrix.html
[35]
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>
[36]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/000
7.html
[36]
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>
[37]http://people.mozilla.org/~cmccormack/tests/cumulative-transform
.svg
[37]
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
[38]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>
[39]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/000
3.html
[39]
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
[40]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
[41]http://www.w3.org/mid/1801756505.20110119200752@w3.org
[41] 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>
[42]http://dev.w3.org/SVG/profiles/1.1F2/publish/conform.html#Confor
mingSVGServers
[42]
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
[43]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>
[44]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/000
2.html
[44]
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>
[45]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectAppr
oved/painting-marker-05-f.html
[45]
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> [46]http://www.w3.org/TR/SVG11/masking.html#OverflowProperty
[46] 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>
[47]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.sv
g
[47] 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
[48]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> [49]http://www.w3.org/Graphics/SVG/WG/track/actions/2930
[49] http://www.w3.org/Graphics/SVG/WG/track/actions/2930
<anthony>
[50]http://www.w3.org/Graphics/SVG/WG/wiki/How_to_determine_dominant
_baseline
[50]
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
Summary of Action Items
[NEW] ACTION: ChrisL to contact Ishida about bidi examples in the
spec to simplify and clarify [recorded in
[51]http://www.w3.org/2011/01/19-svg-minutes.html#action01]
[NEW] ACTION: ChrisL to edit spec for ISSUE-2384 [recorded in
[52]http://www.w3.org/2011/01/19-svg-minutes.html#action02]
[NEW] 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
[53]http://www.w3.org/2011/01/19-svg-minutes.html#action04]
[NEW] ACTION: heycam to make proposed wording for transform
animation accumulation, and make the tests [recorded in
[54]http://www.w3.org/2011/01/19-svg-minutes.html#action03]
[NEW] ACTION: heycam to mark conform-viewers-02-f as unapproved
[recorded in
[55]http://www.w3.org/2011/01/19-svg-minutes.html#action05]
[NEW] ACTION: heycam to research clarifications from i18n people and
mozilla testers [recorded in
[56]http://www.w3.org/2011/01/19-svg-minutes.html#action06]
Received on Wednesday, 19 January 2011 21:09:18 UTC