- 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