- 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