W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2011

SVG WG F2F meeting day 1 (SVG Open 2011)

From: Erik Dahlstrom <ed@opera.com>
Date: Thu, 20 Oct 2011 13:29:41 -0400
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.v3nuvro5geuyw5@mbp-2.local>
html minutes:


text minutes:


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

                                - DRAFT -

                            SVG WG F2F Boston

20 Oct 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/10/20-svg-irc





      * [3]Topics
          1. [4]Connectors
          2. [5]Meshes
          3. [6]inconsistencies between implementations on viewports and
          4. [7]longsonr's annoyances
      * [8]Summary of Action Items

    <scribe> Scribe: Cameron





      [10] http://dev.w3.org/SVG/modules/connector/


      [11] http://dev.w3.org/SVG/modules/connector/SVGConnector.html

    TB: motivated by discussion on the inkscape mailing list in the past
    ... people interested in connectors again
    ... implemented a couple of years ago, a GSoC project
    ... someone suggested maybe we should see what the WG has to say
    about it
    ... or make a proposal to the SVG WG

    DS: do you have a proposal?

    TB: I asked them to make a proposal but they didn't, but I did
    ... I will compare the Inkscape implementation to the WG proposal
    ... both have this idea of a connector
    ... you have an object you're coming from, and one you're going to
    ... a start point on the object and an endpoint
    ... the original implementation had 9 points you could choose from,
    of which only the center point was implemented
    ... you go from the center of the bounding box to the intersection
    of the shape edge in the 8 directions
    ... so I don't think that's a good idea
    ... if you have a star, for example
    ... you probably want to go to the corners
    ... in the SVG proposal, you have this idea of a point
    ... which I think is a good idea. an editor like Inkscape has lots
    of snapping, so you can place it easily.
    ... once it's there one thing to be careful of is the user space
    ... if you scale/rotate the object around, the point should follow

    DS: it should shouldn't it?

    JG: you would just transform it with it

    TB: so that's one difference between the two, and I would favour the
    SVG proposal for that
    ... one thing Inkscape has, it allows you to specify that a
    connector consists of horizontal and vertical line, and it routes
    ... and then you can apply a curvature at the corners
    ... I'm not sure you really want to have the SVG group deal with the
    software of connector avoidance etc.

    DD: almost always when you draw graphs you want lines to avoid nodes

    TB: it's possible, it might make the spec overly complicated
    ... the one thing you have in the SVG proposal is the ability to
    specify a path
    ... so if you want something to avoid something, you can do it by

    DS: while still retaining the semantics of the connection

    TB: I think that's preferable

    DS: no one algorithm that we use is going to satisfy everybody
    ... so it's just an unbounded problem

    TB: I think it might be good to have, if you don't specify the path,
    to do a straight line or a simple horizontal/vertical thing

    DS: a compromise position might be possible, where you might want to
    say that slightly more complex -- you could say that you want a
    direct line, or that it uses only things along the
    horizontal/vertical axes
    ... and whether or not you want rounding on the corners
    ... it would not stop the lines from intersecting, but it would give
    a very simple routing that would solve many use cases

    TB: for keeping lines from intersecting, the problem here (Inkscape)
    is that they're all connected at the center point
    ... but if you move them apart a bit, which you can do with point
    elements, then it will look better

    DD: I can see the ports on a node being autogenerated

    DS: I can see that, it's not something I specified, but I did think
    about that

    TB: not sure how you would do it. you could do that Inkscape
    originally proposed behaviour

    DS: it's the nearest intersection with the stroke
    ... I think we can move forward on a Connectors module unless anyone
    thinks it's a bad idea
    ... rapid prototyping in Inkscape is a good idea

    TB: some things the SVG proposal has that Inkscape doesn't is the
    direction of the connection
    ... that could be implied by having the end and start

    DS: no it's not
    ... you always have an end/start
    ... it's whether it's two way or not

    TB: the ability to specify your own path
    ... the path length
    ... not sure how the path length is used
    ... it might've been so you could back off the length for the

    DS: the pathLength attribute came from copy/paste

    CM: if it's a path like element, I think it makes sense to carry
    that attribute across

    TB: was focusable meant to be there too?

    DS: might've been a stub
    ... my idea, not sure how well I articulated this in the spec...

    [doug draws example on whiteboard]

    [explains accessibility/focusing benefit of implicit relationship
    set up by connectors, whether they are rendered or not]

    ED: if you have path data and you have a d attribute, do you get any
    sort of events when things move around?
    ... or detect it yourself using script?

    DS: I think that's an interested idea
    ... maybe an event when a port has changed
    ... don't know if you want to get an event any time anything changes

    DD: when new connections are created

    DS: or broken
    ... we should think about an API that maximises the ease with which
    somebody can make a library that plugs in to allow for different
    ... what that API looks like I haven't examined
    ... I didn't have custom events in my script implementation
    ... connectioncreated, nodecreated -- when a port on a shape has
    been created
    ... if you have a connection where there would normally be drawn a
    line between things, and the two closest ports have changed --

    [draws example]

    JG: is it even necessary to have that much complexity?
    ... it's not hard to compute the distance between two points
    ... and it's not always what you want

    CM: I'd like to see if something more general than for
    ports/connectors and script layout would be good for this use case

    JG: what might be useful is computing the closest points between two

    CM: that would be nice to have

    DD: there are lots of times you would want two edges to share a port
    as well

    DS: I did make consideration for whether a port could only hold one
    ... just throwing stuff out for API ideas
    ... wrote my script library two years ago, but it didn't have
    sophisticated layout stuff
    ... so rather than get in to specifics, we should look into an API
    so that script could plug in and perform layout

    TB: I looked briefly at what Dia does
    ... Inkscape algorithms do move the arrows from the center, by the
    ... one difference in Dia is that you can specify a Bezier,
    quadratic or cubic, to connect the shapes

    DS: automatically?

    TB: you pick

    DS: but you don't say what the path is, you just say "I want a

    TB: you can control it

    DS: if we're going to have an API for layout, one piece of metadata
    you might want to have is the weight
    ... ascribing a weight to a line
    ... could be useful for the script implemented layout algorithms

    DD: maybe even a vector of numbers, rather than scalars

    DS: if the attribute isn't processed, then it can contain any value,
    including a vector
    ... when I suggested adding a connector element, cyril suggested
    adding this functionality to path, so that it could be used as a

    CC: can't remember saying that, but it would help with backwards

    JG: and having attributes to identify the start/end node

    CC: if the browser does not understand the behaviour it should
    understand the rendering

    DD: some of this edges have a default geometry which is shortest
    line between centroids, which means there is not always some path

    RL: if you add more attributes to path, you're just adding a drag on
    when path is used and not used
    ... DOM node size in memory would increase

    CM: what about child elements to specify this?

    DS: feels unnatural

    TB: you can use a switch element for backwards compatibility

    DS: and if you're using script, you can just detect whether
    connectors are supported

    DD: one API people might want is to have automatic graph rendering
    ... suppose a user builds a graph, and they don't want to lay out
    the coordinates of anything, not even the nodes
    ... or they've only laid out the geometry of the nodes
    ... we'd assume that lines would automatically do the routing

    DS: I think we don't want to do automatic routing, or layout of
    ... but what if there was a layout=auto and the UA could do whatever
    it wanted with the layout

    RL: the inconsistency in rendering would be too much of a problem

    <scribe> ACTION: Doug to add a weight attribute to the connectors
    spec [recorded in

    <trackbot> Created ACTION-3144 - Add a weight attribute to the
    connectors spec [on Doug Schepers - due 2011-10-27].

    <scribe> ACTION: Add attribute for auto straight/curved lines
    between nodes to the connectors spec [recorded in

    <trackbot> Sorry, couldn't find user - Add

    <scribe> ACTION: Doug to Add attribute for auto straight/curved
    lines between nodes to the connectors spec [recorded in

    <trackbot> Created ACTION-3145 - Add attribute for auto
    straight/curved lines between nodes to the connectors spec [on Doug
    Schepers - due 2011-10-27].

    ISSUE: Investigate a script API for listening to object changes to
    facilitate JS layout more easily

    <trackbot> Created ISSUE-2426 - Investigate a script API for
    listening to object changes to facilitate JS layout more easily ;
    please complete additional details at
    [15]http://www.w3.org/Graphics/SVG/WG/track/issues/2426/edit .

      [15] http://www.w3.org/Graphics/SVG/WG/track/issues/2426/edit

    RL: I think this is more useful for authoring tools
    ... in terms of browser implementation, I think there are more
    things important to implement
    ... but to get authoring tools to interoperate I think that would be
    higher on their priority list

    DS: I think giving people some behaviour in browsers for free will
    promote the use of this more
    ... I'm trying to make very minimal additions to what the browsers
    would have to support


    ISSUE: Polylines and maybe other elements might support rounded
    linejoins, like rx/ry for rects

    <trackbot> Created ISSUE-2427 - Polylines and maybe other elements
    might support rounded linejoins, like rx/ry for rects ; please
    complete additional details at
    [16]http://www.w3.org/Graphics/SVG/WG/track/issues/2427/edit .

      [16] http://www.w3.org/Graphics/SVG/WG/track/issues/2427/edit

    CM: tensor control points on the meshes, how useful would they be?

    TB: it would be useful for pdf import at least
    ... cairo supports it

    [tav draws an example of a patch with tensor points]

    [issue with having to specify otherwise missing stops just to give
    the tensor point]

    scribe: another issue do you allow different colours instead of
    using previous colours defined at intersection points of patches
    ... PDF allows mesh patches to share edges in whatever order and

    CC: so you would need to use one mesh per PDF patch, would result in
    a lot of output when converting

    CM: wonder if PDF allows points to have different colours on
    different sides

    CC: you could just have a zero size patch in between

    CM: it's probably not as useful for realistic looking images

    JG: so if PDF already allows strange patch ordering, it will be
    expensive to convert to SVG
    ... if you do exactly what PDF does ...

    TB: it's not good for editing

    JG: if you extend that not just to share one edge, but more than one

    CC: so start with something PDF-like, and add the ability to specify
    which edges are shared

    JG: if we do allow just a grid, and allow that grid edges not be
    shared, then effectively you can draw whatever you want

    CC: I'm fine with going with a grid, but I'd like to see some tests
    ... some examples of grids built with an authoring tool, and some
    made by other means maybe vectorisation tools

    TB: I saw one once where you specify triangles with no order at all,
    and another with arbitrary points
    ... I'd like to know why PDF does it like that

    <scribe> ACTION: Gaurav to ask about PDFs using non-grid gradient
    meshes [recorded in

    <trackbot> Created ACTION-3146 - Ask about PDFs using non-grid
    gradient meshes [on Gaurav Jain - due 2011-10-27].

    TB: another question is path syntax
    ... don't know whether you need to include H/h/V/v
    ... what might be useful is the shortcut curve commands, C/c/S/s

    CM: they don't make sense at every patch edge
    ... you could disallow them in those positions

    CC: it does make sense

    TB: ah it's not so useful after all, because you're not specifying
    the mesh grid lines as a whole
    ... what about Q/q/T/t
    ... trivial conversion but it's probably not worth it
    ... the last issue is arc commands
    ... the algorithm for filling this expects a bezier
    ... so you'd need to convert arcs to beziers
    ... I'm not sure about it
    ... the authoring tools can handle

    CC: so we're introducing a new type, right?
    ... a new datatype
    ... the path attribute would have a different datatype?

    TB: the form of arc that's used for regular paths is not that

    CC: what if you have a path with arc commands and you want to fill
    it with a gradient mesh
    ... now what about the new path commands, catmull-rom and turtle

    CM: if you are disallowing arcs, you should disallow catmull-roms
    ... at maximum, include ones that convert into exactly one bezier

    JG: I know in Inkscape it would be easy to reuse the existing path
    reading code

    RL: it wouldn't be hard to have a flag on the path data reader

    [discussion about which commands to allow]

    CM: z feels a bit funny to me, since it goes to the end point
    instead of the start point of the patch path

    CC: if you leave off a Z, it's like you put a Z anyway yes?

    CM: that would make me happier

    someone: do we need letters at all?

    RESOLUTION: We allow just C/c/L/l in mesh path data
    ... We will leave out tensor control points from gradient meshes
    ... We will not allow multiple colours at mesh intersections, just
    use zero size patches instead

    <scribe> ACTION: Tav to update the mesh gradients page with these
    resolutions [recorded in

    <trackbot> Created ACTION-3147 - Update the mesh gradients page with
    these resolutions [on Tavmjong Bah - due 2011-10-27].

    CC: There's a document called Advanced Gradients Requirements,
    Anthony was editing it
    ... someone asked me to do some fixes to it
    ... I'll make those edits

    <tbah> [19]http://tavmjong.free.fr/SVG/SCHILLER/html.html

      [19] http://tavmjong.free.fr/SVG/SCHILLER/html.html

inconsistencies between implementations on viewports and overflow

    TB: so what do we do about this?

    jwatt was looking into it

    CM: let's make these proper SVG tests for the Integration spec


      [20] https://bugzilla.mozilla.org/show_bug.cgi?id=611099

    ED: the intrinsic sizing fixes in 1.2T got ported over to 1.1SE

    RL: current mozilla thoughts from jwatt on how to resolve the issues

      [21] https://bugzilla.mozilla.org/show_bug.cgi?id=668163#c27

    <scribe> ACTION: Doug to tell Cameron what is wrong with the table
    generating scripts for Integration [recorded in

    <trackbot> Created ACTION-3148 - Tell Cameron what is wrong with the
    table generating scripts for Integration [on Doug Schepers - due

    <scribe> ACTION: Cameron to contact jwatt about SVG sizing to
    summarise his thoughts so we can talk to CSS at TPAC [recorded in

    <trackbot> Created ACTION-3149 - Contact jwatt about SVG sizing to
    summarise his thoughts so we can talk to CSS at TPAC [on Cameron
    McCormack - due 2011-10-27].

longsonr's annoyances

    RL: upper limit for numOctaves
    ... I think Opera has a limit

    CM: and I think IE mentioned he limits it to 10?

    RL: in some of the attributes, you have integer optional integer
    ... but there's no type, it's number optional number
    ... wondering whether it makes sense to have an integer optional
    integer type
    ... I'd like it to cause the attribuet to be invalid if numbers are
    specified in the DOM attribute

    JG: I'd be against putting an explicit limit for numOctaves
    ... it shouldn't make a visible difference where you stop after a

    RL: next, clip
    ... the meaning of the numbers differs between CSS 2.0 and 2.1
    ... would be good to align with CSS 2.1
    ... next, feTurbulence has seed="" which is really an integer, so
    why not make it one instead of a number and defining rounding
    ... next, would like to remove the duplicate SVGLoad, SVGAbort, etc.
    ... we should also drop the requirement to dispatch load to every
    ... next, overflow:auto on markers
    ... doesn't make sense in combination with overflow-x/overflow-y
    ... makes sense in the current firefox implementation, which is
    opposite to what the spec says
    ... so I'd like auto to be equivalent to hidden for markers
    ... next, there's a test with styles on non-containers
    ... presentation attributes on elements to which they have no effect
    ... it's a performance problem
    ... next, are we taking SMIL3's allowReorder into SVG?
    ... some other SMIL3 things have been requested for SVG
    ... would be good to go through SMIL3 to find features we want to

    <ed> [LUNCH]

    <ed> meeting adjourned, we'll discuss the remaining topics at TPAC

    <ed> trackbot, close telcon

    <trackbot> Sorry, ed, I don't understand 'trackbot, close telcon'.
    Please refer to [24]http://www.w3.org/2005/06/tracker/irc for help

      [24] http://www.w3.org/2005/06/tracker/irc

    <ed> trackbot, end meeting

    <ed> trackbot, end meeting

Summary of Action Items

    [NEW] ACTION: Add attribute for auto straight/curved lines between
    nodes to the connectors spec [recorded in
    [NEW] ACTION: Cameron to contact jwatt about SVG sizing to summarise
    his thoughts so we can talk to CSS at TPAC [recorded in
    [NEW] ACTION: Doug to add a weight attribute to the connectors spec
    [recorded in
    [NEW] ACTION: Doug to Add attribute for auto straight/curved lines
    between nodes to the connectors spec [recorded in
    [NEW] ACTION: Doug to tell Cameron what is wrong with the table
    generating scripts for Integration [recorded in
    [NEW] ACTION: Gaurav to ask about PDFs using non-grid gradient
    meshes [recorded in
    [NEW] ACTION: Tav to update the mesh gradients page with these
    resolutions [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [32]scribe.perl version 1.136
     ([33]CVS log)
     $Date: 2011/10/20 17:27:17 $

      [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [33] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [34]http://dev.w3.org/cvsweb/~checkout~/2002

      [34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/node/port/
No ScribeNick specified.  Guessing ScribeNick: heycam
Found Scribe: Cameron

WARNING: No "Present: ... " found!
Possibly Present: CC CM DD DS ISSUE JG RL TB ed https karl karlushi som
eone tbah trackbot
You can indicate people for the Present list like this:
         <dbooth> Present: dbooth jonathan mary
         <dbooth> Present+ amy

Got date from IRC log name: 20 Oct 2011
Guessing minutes URL: [35]http://www.w3.org/2011/10/20-svg-minutes.html
People with action items: add attribute auto between cameron curved dou
g for gaurav lines nodes straight tav

      [35] http://www.w3.org/2011/10/20-svg-minutes.html

    End of [36]scribe.perl diagnostic output]

      [36] 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 Thursday, 20 October 2011 17:30:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC