W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

Minutes, Monday 01 June 2009 SVG WG telcon

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 01 Jun 2009 10:07:32 +0200
To: public-svg-wg@w3.org
Message-ID: <op.uut56o1zgeuyw5@blorp.xn--dahlstrm-t4a.net>
Here are the minutes from the June 1 2009 telcon:


and in text format:


       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

01 Jun 2009



    See also: [3]IRC log

       [3] http://www.w3.org/2009/06/01-svg-irc


           ed, Shepazu, heycam, anthony, ChrisL




      * [4]Topics
          1. [5]Experiment on alternate SVG path syntax for better EXI
          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
    ... for animating, for xslt:ing etc

    DS: another possible advantage would be for connecting things in

    <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

    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

    <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


      [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
    ... 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
    ... also deals with data flavours
    ... maybe that was more of the issue, than the actual moving of the
    ... 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

    <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

    <trackbot> Created ACTION-2586 - Write up scenarios for drag&drop
    and how it should work declaratively etc [on Doug Schepers - due

    <scribe> ACTION: CL to respond to the EXI mail, in
    7.html [recorded in


    <trackbot> Created ACTION-2587 - Respond to the EXI mail, in
    7.html [on Chris Lilley - due 2009-06-08].


ISSUE-2267: Consider removing SVGEvent


    <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

    <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

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
    ... 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

    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

      [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
    ... 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


    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
    [NEW] ACTION: Cameron to reply to the drag&drop email [recorded in
    [NEW] ACTION: cameron to respond to
    [30]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 recorded in
    [NEW] ACTION: CL to mail patrick ion about smooth curves with points
    on path and CC the svg-wg list [recorded in
    [NEW] ACTION: CL to respond to the EXI mail, in
    7.html [recorded in
    [NEW] ACTION: CL to write up proposal for variable stroke-width on
    paths [recorded in
    [NEW] ACTION: DS to write up scenarios for drag&drop and how it
    should work declaratively etc [recorded in

      [30] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930

    [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

      [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
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

      [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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC