- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 3 Feb 2011 10:13:12 +1300
- To: www-svg@w3.org
Unedited minutes from the telcon:
http://www.w3.org/2011/02/02-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
02 Feb 2011
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0102.html
See also: [3]IRC log
[3] http://www.w3.org/2011/02/02-svg-irc
Attendees
Present
tbah, [IPcaller], ed, Shepazu, heycam, +39.524.9.aaaa,
ChrisL, anthony_work, [Microsoft], adrianba
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [4]Topics
1. [5]SVG 1.1 Second Edition progress
* [6]Summary of Action Items
_________________________________________________________
<trackbot> Date: 02 February 2011
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
SVG 1.1 Second Edition progress
CL: i've finally finished off the abbra test, which helps with a few
i think
... you just checked them in erik?
ED: yes i updated the tables
CL: i've also got another implementation from ekioh, which is a 1.2T
implementation, but he claims that it passes 5 tests that we
currently have listed as not being passed
<ChrisL> Ekioh
<ChrisL> > PW> animate-elem-46-t
<ChrisL> > PW> fonts-desc-02-t
<ChrisL> > PW> fonts-glyph-02-t
<ChrisL> > PW> painting-stroke-10-t
<ChrisL> > PW> text-intro-05-t
CL: I haven't run it yet
... i've also been talking with another company, they do an svg to
pdf converter, and they're interested in running the test suite
... that won't help us with any dom tests, but it may help with some
of the static ones
... lastly i can talk to alex, if we have a shortlist of items we
don't pass, we could get him to work on those to fix them
CM: i think we should see which ones we should go for
implementations, and which ones we should drop
CL: animate-elem-46-t we've already got one passing then
<ChrisL> animate-elem-46-t one pass from Opera and Ekioh claim a
pass too
CM: the issue is font-weight animation with discrete/interpolated
values
<ed> <animate attributeName="font-weight" values="bold;normal;bold"
dur="3s" fill="freeze"/>
CL: ask jdagett about whether you can interpolate these
<ed> that's what the test is doing, so depends on how the
interpolation there is meant to work
CL: I think it should interpolate from 0 to 1000
... because there are fonts existing that say their weights that are
not multiples of 100
... 250s, 750s, etc.
... maybe we could just drop that sub-test, split it out
... clarify the issue, and then bring it back as a separate test
... if we think it's correct and we've got two passes then we're all
right...
ED: afaics from firefox it's a timing issue rather than a font
weight issue
... we did recently make a change to animation interpolation code
that we had a bug on, not sure if it affected this test, but i can
check internal builds to see how it goes
... it's possible it looks more like what firefox is doing now
CM: after the call i will test batik/firefox/webkit with the last
subtest removed
<scribe> ACTION: Chris to read css3 fonts and ask jdaggett about
interpolating font-weight animations [recorded in
[7]http://www.w3.org/2011/02/02-svg-minutes.html#action01]
<trackbot> Created ACTION-2936 - Read css3 fonts and ask jdaggett
about interpolating font-weight animations [on Chris Lilley - due
2011-02-09].
<scribe> ACTION: cameron to test batik/firefox/webkit with the last
subtest removed (animate-elem-46-t) [recorded in
[8]http://www.w3.org/2011/02/02-svg-minutes.html#action02]
<trackbot> Created ACTION-2937 - Test batik/firefox/webkit with the
last subtest removed (animate-elem-46-t) [on Cameron McCormack - due
2011-02-09].
<ChrisL> filters-light-02-f
CL: is this something that's been changed because of errata?
ED: yes, from memory
CL: so some of this is stable stuff and some just changed 6 months
ago
CM: is this one affected by anthony's direction of the light
erratum?
ED: it might be
AG: i will check
ED: it's about the same thing
<ed> ISSUE-2339?
<trackbot> ISSUE-2339 -- Last Call Comment: definition of azimuth,
elevation for feDistantLight -- open
<trackbot> [9]http://www.w3.org/Graphics/SVG/WG/track/issues/2339
[9] http://www.w3.org/Graphics/SVG/WG/track/issues/2339
CL: opera is the only one that passes
... so we should lean on someone to fix it
AG: i think in the spec we've got it wrong
TB: inkscape does it backwards
... let me check
CL: if the spec is wrong or ambiguous, and inkscape has copied the
spec, and we've now corrected the spec...
TB: i ran the test automatically and with our test harness it failed
... but when i open it in inkscape it passes, but the reference
image is just a bit lighter
CL: i wouldn't worry about that too much
TB: we pass, then
CL: what about -03?
TB: that one we don't get the primitiveUnits=objectBoundingBox one
correct
ED: so from our experience, the primitiveUnits thing is a day of
work, not too hard, mostly just converting the coordinates
... if you have everything else in place it shouldn't be that hard
to implement
TB: i'm not sure whether we do objectBoundingBox correct anywhere
<ed>
[10]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-light-03-f
.svg
[10] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-light-03-f.svg
<ChrisL>
file://localhost/D:/WWW/dev/SVG/profiles/1.1F2/test/svg/filters-ligh
t-03-f.svg
AG: looking at filters-light-02 i think we should be fine re the
erratum
... since the test is testing azimuth, but the erratum is about
elevation
... the difference might be a darker or lighter arc
<scribe> ACTION: cameron to look at batik for filters-light-03
[recorded in
[11]http://www.w3.org/2011/02/02-svg-minutes.html#action03]
<trackbot> Created ACTION-2938 - Look at batik for filters-light-03
[on Cameron McCormack - due 2011-02-09].
<ed>
[12]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-overview-0
1-b.svg
[12] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-overview-01-b.svg
<ChrisL> filters-overview-01-b.svg
CM: firefox doesn't implement those four inputs
TB: inkscape doesn't do fillpaint/strokepaint
CL: i noticed the ones that fail in firefox are different from those
that fail in batik
... firefox doesn't do backgroundimage/backgroundalpha
CM: and fillpaint/fillstroke
... not sure how easy batik is to fix
... backgroundimage/backgroundalpha are harder to implement
<scribe> ACTION: cameron to look into batik failing
filters-overview-01 [recorded in
[13]http://www.w3.org/2011/02/02-svg-minutes.html#action04]
<trackbot> Created ACTION-2939 - Look into batik failing
filters-overview-01 [on Cameron McCormack - due 2011-02-09].
<ed>
[14]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-desc-04-t.sv
g
[14] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-desc-04-t.svg
CL: abbra only has some small problems with italic/oblique
... maybe it can be fixed
CM: seems like this test might be passed by some tiny
implementations
ED: for opera it's the last line that fails
CL: and i think that's a css 2.1 conformance failure
CM: what's it testing specifically?
<ChrisL> Italic can match against oblique or italic, but all other
values must match exactly.
CM: seems like it should be a simple fix then
<scribe> ACTION: erik to look at opera failing fonts-desc-04
[recorded in
[15]http://www.w3.org/2011/02/02-svg-minutes.html#action05]
<trackbot> Created ACTION-2940 - Look at opera failing fonts-desc-04
[on Erik Dahlström - due 2011-02-09].
<scribe> ACTION: cameron to look into batik failing fonts-desc-04
[recorded in
[16]http://www.w3.org/2011/02/02-svg-minutes.html#action06]
<trackbot> Created ACTION-2941 - Look into batik failing
fonts-desc-04 [on Cameron McCormack - due 2011-02-09].
<ed>
[17]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-desc-05-t.sv
g
[17] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-desc-05-t.svg
ED: fonts-desc-05, is that testing the same thing? or something
different?
CL: this is testing smallcaps or not, also testing the oblique thing
CM: seems to be testing precedence of the font descriptors too,
looking at the pass criteria
<scribe> ACTION: cameron to check batik for fonts-desc-05 [recorded
in [18]http://www.w3.org/2011/02/02-svg-minutes.html#action07]
<trackbot> Created ACTION-2942 - Check batik for fonts-desc-05 [on
Cameron McCormack - due 2011-02-09].
ED: might be hard for us to deal with, we do synthesis of smallcaps
... i think the fonts don't have uppercase glyphs
... so we would go to the missing glyph
CL: so you never use the real small cap font, only the synthesized
one?
<scribe> ACTION: Erik to check opera for fonts-desc-05, but no
promises! [recorded in
[19]http://www.w3.org/2011/02/02-svg-minutes.html#action08]
<trackbot> Created ACTION-2943 - Check opera for fonts-desc-05, but
no promises! [on Erik Dahlström - due 2011-02-09].
<ed>
[20]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-glyph-02-t.s
vg
[20] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-glyph-02-t.svg
ED: i know this one passes in internal builds
CL: it should be fairly easy, if you do svg fonts
... on the <glyph> element there's an arabic-form attribute
... which says whether it's isolated, medial, etc.
... that's what it's testing
ED: we could change it to use text-anchor=middle
... same in opera, it will pass with text-anchor=middle
<ChrisL> I just checked in the change on CVS
CM: not sure about this text-anchor issue
ED: the text has been backported from 1.2T
CL: the tests need fixing for those text-anchor issues
<scribe> ACTION: erik to regenerate reference image for
fonts-glyph-02 [recorded in
[21]http://www.w3.org/2011/02/02-svg-minutes.html#action09]
<trackbot> Created ACTION-2944 - Regenerate reference image for
fonts-glyph-02 [on Erik Dahlström - due 2011-02-09].
<ed>
[22]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-glyph-03-t.s
vg
[22] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/fonts-glyph-03-t.svg
CM: huh, i didn't know <glyph> had lang=""
CL: it's because of CJK unification, to select between different
versions of character for chinese and japanese etc.
<scribe> ACTION: cameron to look into fonts-glyph-03 with no
guarantees [recorded in
[23]http://www.w3.org/2011/02/02-svg-minutes.html#action10]
<trackbot> Created ACTION-2945 - Look into fonts-glyph-03 with no
guarantees [on Cameron McCormack - due 2011-02-09].
ACTION-2945: for batik
<trackbot> ACTION-2945 Look into fonts-glyph-03 with no guarantees
notes added
<ed>
[24]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/interact-pevents-0
4-t.svg
[24] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/interact-pevents-04-t.svg
ED: i could live with fonts-glyph-03 being dropped for now
<scribe> ACTION: Erik to change the font in fonts-glyph-03 to make
the space glyphs be blank [recorded in
[25]http://www.w3.org/2011/02/02-svg-minutes.html#action11]
<trackbot> Created ACTION-2946 - Change the font in fonts-glyph-03
to make the space glyphs be blank [on Erik Dahlström - due
2011-02-09].
<ed>
[26]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/linking-uri-01-b.s
vg
[26] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/linking-uri-01-b.svg
CL: this is also affected by errata
... svg use to say bare fragments mean nothing
... we changed it to mean centered on the thing with that id
... there's a seaprate issue about highlighting it, which i think we
decided you shouldn't have to
... but the moving the viewport probably would be an easy thing
... if you already do views, it should be easy
<ed> [27]http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html
[27] http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html
<shepazu>
[28]http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html#SVGFra
gmentIdentifiers
[28] http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html#SVGFragmentIdentifiers
DS: there may be UAs out there that do this, maybe we can change the
spec to say "UAs can do highlighting if they support :target"
<scribe> ACTION: Chris to propose wording for highlighting and
:target [recorded in
[29]http://www.w3.org/2011/02/02-svg-minutes.html#action12]
<trackbot> Created ACTION-2947 - Propose wording for highlighting
and :target [on Chris Lilley - due 2011-02-09].
<ChrisL> viewTarget = "XML_Name [XML_NAME]*"
<ChrisL> Indicates the target object associated with the view. If
provided, then the target element(s) will be highlighted.
<scribe> ACTION: Chris to change linking-uri-01 and linking-uri-02
to remove the requirement to highlight [recorded in
[30]http://www.w3.org/2011/02/02-svg-minutes.html#action13]
<trackbot> Created ACTION-2948 - Change linking-uri-01 and
linking-uri-02 to remove the requirement to highlight [on Chris
Lilley - due 2011-02-09].
<ed>
[31]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/painting-render-02
-b.svg
[31] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/painting-render-02-b.svg
CM: it should be testing alpha compositing with color-interpolation
... nobody passes, and comments saying that the test is wrong
CL: let's unapprove it
<scribe> ACTION: Cameron to unapprove painting-render-02-b [recorded
in [32]http://www.w3.org/2011/02/02-svg-minutes.html#action14]
<trackbot> Created ACTION-2949 - Unapprove painting-render-02-b [on
Cameron McCormack - due 2011-02-09].
<ed>
[33]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/painting-stroke-10
-t.svg
[33] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/painting-stroke-10-t.svg
<ChrisL> This tests that stroking of zero length subpaths will
result in
<ChrisL> some rendering if the 'stroke-linecap' property is set to
<ChrisL> 'square' or 'round', but not if it is set to 'butt'.
CM: jwatt has a patch for this, but it hasn't been approved to be
landed yet
<ChrisL>
[34]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectAppr
oved/
[34] http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/
ED: we have a bunch of bugs on zero length paths, and i don't think
any of those are close to being fixed
CM: it's probably not simple in batik, or in webkit
<scribe> ACTION: Cameron to see how easy painting-stroke-10-t is to
fix in Batik [recorded in
[35]http://www.w3.org/2011/02/02-svg-minutes.html#action15]
<trackbot> Created ACTION-2950 - See how easy painting-stroke-10-t
is to fix in Batik [on Cameron McCormack - due 2011-02-09].
<ed>
[36]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-dom-15-f.sv
g
[36] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-dom-15-f.svg
CM: seems to be doing the use element correctly with event dispatch
<shepazu> ISSUE: for SVG2 / SVG Fonts, describe rational for @lang
on <glyph>, e.g. because of CJK unification, to select between
different versions of character for chinese and japanese etc.
<trackbot> Created ISSUE-2399 - For SVG2 / SVG Fonts, describe
rational for @lang on <glyph>, e.g. because of CJK unification, to
select between different versions of character for chinese and
japanese etc. ; please complete additional details at
[37]http://www.w3.org/Graphics/SVG/WG/track/issues/2399/edit .
[37] http://www.w3.org/Graphics/SVG/WG/track/issues/2399/edit
<scribe> ACTION: Cameron to review struct-dom-15 [recorded in
[38]http://www.w3.org/2011/02/02-svg-minutes.html#action16]
<trackbot> Created ACTION-2951 - Review struct-dom-15 [on Cameron
McCormack - due 2011-02-09].
ED: we can split it up
<scribe> ACTION: Patrick to review struct-dom-15 [recorded in
[39]http://www.w3.org/2011/02/02-svg-minutes.html#action17]
<trackbot> Created ACTION-2952 - Review struct-dom-15 [on Patrick
Dengler - due 2011-02-09].
[40]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectAppr
oved/struct-dom-15-f.html
[40] http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/struct-dom-15-f.html
<scribe> ACTION: Cameron to look into off-colors in reference images
on mac [recorded in
[41]http://www.w3.org/2011/02/02-svg-minutes.html#action18]
<trackbot> Created ACTION-2953 - Look into off-colors in reference
images on mac [on Cameron McCormack - due 2011-02-09].
<ed>
[42]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.sv
g
[42] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.svg
CL: abbra passes -08 but not -07
... in unicode there are tables to determine which glyphs go from
which baselines
PD: we only have two fonts that support ideographic baseline
<ChrisL> the problem is that for OT/TT fonts, there can be no
baseline info at all so what should it align to?
<ChrisL> the svg version of the test has explicit baseline infor for
all four lines
<ChrisL> so is the test correct, i am saying
CM: (summarises some fx tf discussions)
... if we will unapprove one we should unapprove both
<ChrisL> don't follow; one has explicit info and the other has
implicit or missing info
ChrisL, ah you dropped off
ChrisL, I'll mail you a summary of what we discussed, since we're
out of time now anyway
<ChrisL> yes I get dropped after 40 minutes
<ChrisL> ok
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 2 February 2011 21:14:54 UTC