- 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>
html minutes:
http://www.w3.org/2011/10/20-svg-minutes.html
text minutes:
[1]W3C
[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
Attendees
Present
Regrets
Chair
Erik
Scribe
Cameron
Contents
* [3]Topics
1. [4]Connectors
2. [5]Meshes
3. [6]inconsistencies between implementations on viewports and
overflow
4. [7]longsonr's annoyances
* [8]Summary of Action Items
_________________________________________________________
<scribe> Scribe: Cameron
[9]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2011/agenda_pr
oposals
[9]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2011/agenda_proposals
Connectors
[10]http://dev.w3.org/SVG/modules/connector/
[10] http://dev.w3.org/SVG/modules/connector/
[11]http://dev.w3.org/SVG/modules/connector/SVGConnector.html
[11] 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
[12]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
[13]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
[14]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
[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
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
[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
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
[17]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
[18]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> [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
[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
[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
[22]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
[23]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 [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
[25]http://www.w3.org/2011/10/20-svg-minutes.html#action02]
[NEW] ACTION: Cameron to contact jwatt about SVG sizing to summarise
his thoughts so we can talk to CSS at TPAC [recorded in
[26]http://www.w3.org/2011/10/20-svg-minutes.html#action07]
[NEW] ACTION: Doug to add a weight attribute to the connectors spec
[recorded in
[27]http://www.w3.org/2011/10/20-svg-minutes.html#action01]
[NEW] ACTION: Doug to Add attribute for auto straight/curved lines
between nodes to the connectors spec [recorded in
[28]http://www.w3.org/2011/10/20-svg-minutes.html#action03]
[NEW] ACTION: Doug to tell Cameron what is wrong with the table
generating scripts for Integration [recorded in
[29]http://www.w3.org/2011/10/20-svg-minutes.html#action06]
[NEW] ACTION: Gaurav to ask about PDFs using non-grid gradient
meshes [recorded in
[30]http://www.w3.org/2011/10/20-svg-minutes.html#action04]
[NEW] ACTION: Tav to update the mesh gradients page with these
resolutions [recorded in
[31]http://www.w3.org/2011/10/20-svg-minutes.html#action05]
[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
/scribe/
[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:20 UTC