- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 01 Jun 2009 10:07:32 +0200
- To: public-svg-wg@w3.org
Here are the minutes from the June 1 2009 telcon: http://www.w3.org/2009/06/01-svg-minutes.html and in text format: [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 01 Jun 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html See also: [3]IRC log [3] http://www.w3.org/2009/06/01-svg-irc Attendees Present ed, Shepazu, heycam, anthony, ChrisL Regrets Chair Cameron Scribe Erik Contents * [4]Topics 1. [5]Experiment on alternate SVG path syntax for better EXI compression 2. [6]Native support for Drag & Drop in SVG 3. [7]ISSUE-2267: Consider removing SVGEvent 4. [8]Plans for SVG 1.1 test suite, missing test coverage 5. [9]Multiple <missing-glyph> 6. [10]google i/o 7. [11]F2F * [12]Summary of Action Items _________________________________________________________ <trackbot> Date: 01 June 2009 <scribe> scribeNick: ed <scribe> scribe: Erik Experiment on alternate SVG path syntax for better EXI compression CM: haven't yet had time to read the PDF CL: i have, if you make the markup more verbose EXI is able to compress it better ... no studies of whether gzip or EXI is more efficient ... but we have talked about adding path syntax in next major svg version ... for animating, for xslt:ing etc DS: another possible advantage would be for connecting things in layout <ChrisL> yup, can put an id on individual path commands DS: also for markers, we could have richer ways of addressing individual path segments CL: ...??... event listeners AG: using that method you get good EXI compression DS: CL has a point in that the study isn't complete ... or maybe EXI is done? ... can you do both EXI and gzip at the same time? CL: yes, but it's like gzipping a jpeg file <ChrisL> also, once the schema is expanded to allow event listeners, etc the exi compression will be less efficient DS: we could go for two syntaxes, one for compression AG: would like to think of the same syntax for transforms as well ... you could reuse the transforms, without using a group DS: just wondering if people would then ask for a z-index attribute on a path segment ... would be useful if the study could look at existing svg content, e.g from wikipedia ... could write a script to convert into EXI syntax ... what are the statistics, what files have been tested? CL: not given in the study DS: we should ask them for statistics, and references to what files have been tested, and also how it compares to gzip ... and that people can put id attributes on child elements, how does that affect performance/compression? CL: id is the least of their worries, if you put presentation attributes everywhere that might mean it's less efficient, we should ask about that too DS: stroke could be meaningful, for individual path segments CL: inheritance of properties... DS: we should ask these questions, and ask what the consequences of our changes would be ... nurbs would be nice to have too CL: yeah, but in new element in that case <ChrisL> yes, though not added to path - better to be its own element so they can be tweened etc AG: would like to restrict z-index to group elements DS: at the f2f we should talk about the consequences of breaking up the path syntax would be ... and what it wiold mean to change the fill on one segment CL: might change the fill of markers on that segment possibly CM: would this help with calligraphic strokes? variable strokewidth... CL: the idea of having a width gradient, an element that has a number of width stops, and you apply that to a path DS: another aspect, ppl don't always want the strokewidth to be the same on both sides ... 0, 20, 10; 0 blah... sequences where one would be the inner and one would be the outer strokewidth CL: you want a right stop and a left stop DS: or do percentages of the pathlength, say at 70% along the path it's 20px wide CL: two modes, one relative to the overall strokewidth, and one would be absolute <ChrisL> its like objectboundingbox except the dimensions are different, the rectangle is the length of the path times the width <ChrisL> width can be absolute or relative (to the stroke width) CM: seems like a topic for the f2f <scribe> ACTION: CL to write up proposal for variable stroke-width on paths [recorded in [13]http://www.w3.org/2009/06/01-svg-minutes.html#action01] <trackbot> Created ACTION-2583 - Write up proposal for variable stroke-width on paths [on Chris Lilley - due 2009-06-08]. Native support for Drag & Drop in SVG <heycam> [14]http://lists.w3.org/Archives/Public/www-svg/2009May/0053.html [14] http://lists.w3.org/Archives/Public/www-svg/2009May/0053.html CM: featurerequest for simpler way of doing drag&drop DS: there's a drag&drop element attribute being defined in the webapps wg, and also in html5 ... a more robust way of doing it might be to extend the layout syntax ... if you just have drag & drop elements, you'd need scripts to drive it ... it would be possible to use smil only CM: i wouldn't like drag&dropiping if it just added a transform or something ... also deals with data flavours ... maybe that was more of the issue, than the actual moving of the graphic ... that part (data side) is being handled by html/webapps...would like that to be the same DS: chaals and I were editing this in the webapps wg ... there might be cases where you want to paste the rasterized version of the graphic, the title of the graphic...what you are grabbing is complex ... do you drag just one element, what about sizes etc ... and what if you drop it into another document (or somewhere which doesn't support svg) ... it's a different issue from moving things around though ... I started working on the connector element (SVG Integration?) <scribe> ACTION: CL to mail patrick ion about smooth curves with points on path and CC the svg-wg list [recorded in [15]http://www.w3.org/2009/06/01-svg-minutes.html#action02] <trackbot> Created ACTION-2584 - Mail patrick ion about smooth curves with points on path and CC the svg-wg list [on Chris Lilley - due 2009-06-08]. <scribe> ACTION: Cameron to reply to the drag&drop email [recorded in [16]http://www.w3.org/2009/06/01-svg-minutes.html#action03] <trackbot> Created ACTION-2585 - Reply to the drag&drop email [on Cameron McCormack - due 2009-06-08]. DS: ppl might want to do math while dragging, the size of the thing increases or something....might be nice to have declarative way of doing that <scribe> ACTION: DS to write up scenarios for drag&drop and how it should work declaratively etc [recorded in [17]http://www.w3.org/2009/06/01-svg-minutes.html#action04] <trackbot> Created ACTION-2586 - Write up scenarios for drag&drop and how it should work declaratively etc [on Doug Schepers - due 2009-06-08]. <scribe> ACTION: CL to respond to the EXI mail, in [18]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/017 7.html [recorded in [19]http://www.w3.org/2009/06/01-svg-minutes.html#action05] [18] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html <trackbot> Created ACTION-2587 - Respond to the EXI mail, in [20]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/017 7.html [on Chris Lilley - due 2009-06-08]. [20] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html ISSUE-2267: Consider removing SVGEvent ISSUE-2267? <trackbot> ISSUE-2267 -- Consider removing SVGEvent -- RAISED <trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2267 [21] http://www.w3.org/Graphics/SVG/WG/track/issues/2267 CM: can we drop the SVGEvent interface? ... it extends Event, but doens't add anything on it CL: we added it so that we could extend it if we needed it I think CM: there's no real need for having the interface ED: it's not used in the spec? CM: well, it's used but is no different from Event DS: how would this affect UA:s? CL: not exposed really CM: we don't distinguish between Event and SVGEvent <scribe> ACTION: Cameron to remove the SVGEvent interface in SVG 1.1F2 [recorded in [22]http://www.w3.org/2009/06/01-svg-minutes.html#action06] <trackbot> Created ACTION-2588 - Remove the SVGEvent interface in SVG 1.1F2 [on Cameron McCormack - due 2009-06-08]. Plans for SVG 1.1 test suite, missing test coverage CL: the long list of tests there should be autogenerated? ... some of the tests are ok, but some can't be tested unless you have a UA that supports some extension feature CM: semiautomated was the thought ... we can look at this at the f2f ... I'd like to decide which are testable and to make tests for them ... and split them among ourselves ... seems like a good idea to republish the testsuite at the same time as the 1.1F2 ... we may be gated on the testsuite <ChrisL> yes, but if the testing takes too long we should release the spec anyway, as its valuable to have a spec with errata rolled in Multiple <missing-glyph> CL: responded to that ... the whole point is to display a missing glyph, ... it's undefined in CSS ... you can pick the missingglyph from another source CM: do we say about glyph selection? CL: we do what CSS says <ChrisL> [23]http://www.w3.org/TR/CSS21/fonts.html#algorithm [23] http://www.w3.org/TR/CSS21/fonts.html#algorithm CM: should we have it in our spec though? CL: yeah, we use the fontselection algorithm, from css CM: does it mean it can pick a font you didn't list in font-family? CL: yes ... by default it uses a special unicode font which shows the codepoint ... answer should be yes, we know, it's not a problem CM: if that's what we require, then I guess it wouldn't be good to diverge from that ... in the CSS3 font matching algorithm, has it been updated? CL: not sure, will check <heycam> 6. If a particular character cannot be displayed using any font, the user agent should indicate by some means that a character is not being displayed, either by displaying a symbolic representation of the missing glyph or using the ‘missing character’ glyph from another font. <ChrisL> its step 6 in [24]http://dev.w3.org/csswg/css3-fonts/#font-matching [24] http://dev.w3.org/csswg/css3-fonts/#font-matching CL: the basis is the same though ... allows missingglyph from any font <scribe> ACTION: cameron to respond to [25]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 recorded in [26]http://www.w3.org/2009/06/01-svg-minutes.html#action07] [25] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 <trackbot> Created ACTION-2589 - Respond to [27]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 on Cameron McCormack - due 2009-06-08]. [27] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 google i/o DS: talked to brad neuberg, who's working on the shim ... making good progress ... release hopefully ready by svg open AG: shim? DS: shim is like a plugin, but isn't really, it's a script library that enables functionality ... this one uses flash to render SVG, and it should work with existing code ... like a svg virtual machine ... IE users are slow to upgrade ... even if IE supported SVG in the next version it would take years before ppl could use it ... the shim also gives consistent results across browsers (ED: though that does require plugins are enabled) ... gives consistent look&feel ... talked about the params spec with google guys ... the shim can be rolled out much faster than a browser, and it's opensource ... could help svg specs move along faster too CL: could help ppl with the ASV issue, helps SVG ... slightly worrying that the shim might decide the featureset DS: well it has a short releasecycle, and it's opensource CL: svg tiny 1.2 stuff? DS: I suspect textwrapping in svg would be one thing ... zooming is one thing which would help some UAs like firefox CL: risk of slowing down browser implementations ... it's good as a move from ASV still, and for adding features DS: also connected with the google wave guys ... interested in dom 3 events, the key events stuff ... to get it folded it into webkit / chrome F2F DS: please send me your travel info ... AG you'll be dialing in? AG: yep rrs-agent, make minutes Summary of Action Items [NEW] ACTION: Cameron to remove the SVGEvent interface in SVG 1.1F2 [recorded in [28]http://www.w3.org/2009/06/01-svg-minutes.html#action06] [NEW] ACTION: Cameron to reply to the drag&drop email [recorded in [29]http://www.w3.org/2009/06/01-svg-minutes.html#action03] [NEW] ACTION: cameron to respond to [30]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 recorded in [31]http://www.w3.org/2009/06/01-svg-minutes.html#action07] [NEW] ACTION: CL to mail patrick ion about smooth curves with points on path and CC the svg-wg list [recorded in [32]http://www.w3.org/2009/06/01-svg-minutes.html#action02] [NEW] ACTION: CL to respond to the EXI mail, in [33]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/017 7.html [recorded in [34]http://www.w3.org/2009/06/01-svg-minutes.html#action05] [NEW] ACTION: CL to write up proposal for variable stroke-width on paths [recorded in [35]http://www.w3.org/2009/06/01-svg-minutes.html#action01] [NEW] ACTION: DS to write up scenarios for drag&drop and how it should work declaratively etc [recorded in [36]http://www.w3.org/2009/06/01-svg-minutes.html#action04] [30] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 [33] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html [End of minutes] _________________________________________________________ Minutes formatted by David Booth's [37]scribe.perl version 1.135 ([38]CVS log) $Date: 2009/06/01 08:04:10 $ _________________________________________________________ [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [38] http://dev.w3.org/cvsweb/2002/scribe/ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at [39]http://dev.w3.org/cvsweb/~checkout~/2002 /scribe/ [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/9/(/ Found ScribeNick: ed Found Scribe: Erik Default Present: ed, Shepazu, heycam, anthony, ChrisL Present: ed Shepazu heycam anthony ChrisL Agenda: [40]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJu n/0177.html Found Date: 01 Jun 2009 Guessing minutes URL: [41]http://www.w3.org/2009/06/01-svg-minutes.html People with action items: cameron cl ds [40] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html [41] http://www.w3.org/2009/06/01-svg-minutes.html End of [42]scribe.perl diagnostic output] [42] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 1 June 2009 08:08:41 UTC