SVG Working Group Teleconference -- 01 Jun 2009

<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 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> 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 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 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 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 http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html [recorded in http://www.w3.org/2009/06/01-svg-minutes.html#action05]

<trackbot> Created ACTION-2587 - Respond to the EXI mail, in http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html [on Chris Lilley - due 2009-06-08].

ISSUE-2267: Consider removing SVGEvent

ISSUE-2267?

<trackbot> ISSUE-2267 -- Consider removing SVGEvent -- RAISED

<trackbot> 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 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> 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 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 http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 [recorded in http://www.w3.org/2009/06/01-svg-minutes.html#action07]

<trackbot> Created ACTION-2589 - Respond to http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 [on Cameron McCormack - due 2009-06-08].

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

- DRAFT -

SVG Working Group Teleconference

01 Jun 2009

Attendees

Contents