SVG WG F2F Boston -- 20 Oct 2011

<scribe> Scribe: Cameron

http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2011/agenda_proposals

Connectors

http://dev.w3.org/SVG/modules/connector/

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

TB: motivated by discussion on the inkscape mailing list in the past month
... 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 hand

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 markers?

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

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 connection
... 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 way
... 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 cubic"?

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 fallback

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

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 geometry

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 nodes
... 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 http://www.w3.org/2011/10/20-svg-minutes.html#action01]

<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 http://www.w3.org/2011/10/20-svg-minutes.html#action02]

<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 http://www.w3.org/2011/10/20-svg-minutes.html#action03]

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

Meshes

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

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 edge

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 http://www.w3.org/2011/10/20-svg-minutes.html#action04]

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

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 graphics?

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 http://www.w3.org/2011/10/20-svg-minutes.html#action05]

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

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 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 http://www.w3.org/2011/10/20-svg-minutes.html#action06]

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

<scribe> ACTION: Cameron to contact jwatt about SVG sizing to summarise his thoughts so we can talk to CSS at TPAC [recorded in http://www.w3.org/2011/10/20-svg-minutes.html#action07]

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

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

<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 http://www.w3.org/2005/06/tracker/irc for help

<ed> trackbot, end meeting

- DRAFT -

SVG WG F2F Boston

20 Oct 2011

Attendees

Contents

Connectors

Meshes

inconsistencies between implementations on viewports and overflow

longsonr's annoyances

Summary of Action Items

Scribe.perl diagnostic output