IRC log of svg on 2011-10-20

Timestamps are in UTC.

13:33:36 [RRSAgent]
RRSAgent has joined #svg
13:33:36 [RRSAgent]
logging to http://www.w3.org/2011/10/20-svg-irc
13:34:01 [tbah]
tbah has joined #svg
13:34:05 [heycam]
Meeting: SVG WG F2F Boston
13:34:11 [heycam]
Chair: Erik
13:34:13 [heycam]
Scribe: Cameron
13:34:16 [heycam]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2011/agenda_proposals
13:35:07 [heycam]
Topic: Connectors
13:35:48 [heycam]
http://dev.w3.org/SVG/modules/connector/
13:36:12 [heycam]
http://dev.w3.org/SVG/modules/connector/SVGConnector.html
13:38:38 [heycam]
TB: motivated by discussion on the inkscape mailing list in the past month
13:38:42 [heycam]
... people interested in connectors again
13:38:48 [heycam]
... implemented a couple of years ago, a GSoC project
13:39:00 [heycam]
... someone suggested maybe we should see what the WG has to say about it
13:39:05 [heycam]
... or make a proposal to the SVG WG
13:39:12 [heycam]
DS: do you have a proposal?
13:39:21 [heycam]
TB: I asked them to make a proposal but they didn't, but I did
13:39:28 [heycam]
... I will compare the Inkscape implementation to the WG proposal
13:39:36 [heycam]
... both have this idea of a connector
13:39:58 [heycam]
... you have an object you're coming from, and one you're going to
13:40:04 [heycam]
... a start point on the object and an endpoint
13:40:17 [heycam]
... the original implementation had 9 points you could choose from, of which only the center point was implemented
13:40:28 [heycam]
... you go from the center of the bounding box to the intersection of the shape edge in the 8 directions
13:40:32 [heycam]
... so I don't think that's a good idea
13:40:41 [heycam]
... if you have a star, for example
13:40:59 [heycam]
... you probably want to go to the corners
13:41:05 [heycam]
... in the SVG proposal, you have this idea of a point
13:41:18 [heycam]
... which I think is a good idea. an editor like Inkscape has lots of snapping, so you can place it easily.
13:41:27 [heycam]
... once it's there one thing to be careful of is the user space
13:41:37 [heycam]
... if you scale/rotate the object around, the point should follow
13:41:49 [heycam]
DS: it should shouldn't it?
13:42:00 [heycam]
JG: you would just transform it with it
13:42:43 [heycam]
TB: so that's one difference between the two, and I would favour the SVG proposal for that
13:43:03 [heycam]
... one thing Inkscape has, it allows you to specify that a connector consists of horizontal and vertical line, and it routes
13:43:13 [heycam]
... and then you can apply a curvature at the corners
13:44:09 [heycam]
... I'm not sure you really want to have the SVG group deal with the software of connector avoidance etc.
13:44:18 [heycam]
DD: almost always when you draw graphs you want lines to avoid nodes
13:44:40 [heycam]
TB: it's possible, it might make the spec overly complicated
13:44:51 [heycam]
... the one thing you have in the SVG proposal is the ability to specify a path
13:44:57 [heycam]
... so if you want something to avoid something, you can do it by hand
13:45:04 [heycam]
DS: while still retaining the semantics of the connection
13:45:06 [heycam]
TB: I think that's preferable
13:45:13 [heycam]
DS: no one algorithm that we use is going to satisfy everybody
13:45:17 [heycam]
... so it's just an unbounded problem
13:45:30 [heycam]
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
13:45:58 [heycam]
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
13:46:04 [heycam]
... and whether or not you want rounding on the corners
13:46:21 [heycam]
... it would not stop the lines from intersecting, but it would give a very simple routing that would solve many use cases
13:46:38 [heycam]
TB: for keeping lines from intersecting, the problem here (Inkscape) is that they're all connected at the center point
13:46:49 [heycam]
... but if you move them apart a bit, which you can do with point elements, then it will look better
13:46:57 [heycam]
DD: I can see the ports on a node being autogenerated
13:47:11 [heycam]
DS: I can see that, it's not something I specified, but I did think about that
13:47:21 [heycam]
TB: not sure how you would do it. you could do that Inkscape originally proposed behaviour
13:47:33 [heycam]
DS: it's the nearest intersection with the stroke
13:48:34 [heycam]
... I think we can move forward on a Connectors module unless anyone thinks it's a bad idea
13:48:49 [heycam]
... rapid prototyping in Inkscape is a good idea
13:49:55 [heycam]
TB: some things the SVG proposal has that Inkscape doesn't is the direction of the connection
13:50:01 [heycam]
... that could be implied by having the end and start
13:50:05 [heycam]
DS: no it's not
13:50:11 [heycam]
... you always have an end/start
13:50:14 [heycam]
... it's whether it's two way or not
13:50:18 [heycam]
TB: the ability to specify your own path
13:50:21 [heycam]
... the path length
13:50:26 [heycam]
... not sure how the path length is used
13:50:42 [heycam]
... it might've been so you could back off the length for the markers?
13:51:37 [heycam]
DS: the pathLength attribute came from copy/paste
13:52:07 [heycam]
CM: if it's a path like element, I think it makes sense to carry that attribute across
13:52:15 [heycam]
TB: was focusable meant to be there too?
13:52:18 [heycam]
DS: might've been a stub
13:52:44 [heycam]
... my idea, not sure how well I articulated this in the spec...
13:52:48 [heycam]
[doug draws example on whiteboard]
13:58:20 [heycam]
[explains accessibility/focusing benefit of implicit relationship set up by connectors, whether they are rendered or not]
13:58:50 [heycam]
ED: if you have path data and you have a d attribute, do you get any sort of events when things move around?
13:58:55 [heycam]
... or detect it yourself using script?
13:59:04 [heycam]
DS: I think that's an interested idea
13:59:08 [heycam]
... maybe an event when a port has changed
13:59:15 [heycam]
... don't know if you want to get an event any time anything changes
13:59:23 [heycam]
DD: when new connections are created
13:59:24 [heycam]
DS: or broken
14:00:43 [heycam]
... 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
14:00:59 [heycam]
... what that API looks like I haven't examined
14:01:04 [heycam]
... I didn't have custom events in my script implementation
14:01:27 [heycam]
... connectioncreated, nodecreated -- when a node on a shape has been created
14:01:52 [heycam]
s/node/port/
14:02:19 [heycam]
... if you have a connection where there would normally be drawn a line between things, and the two closest ports have changed --
14:02:22 [heycam]
[draws example]
14:05:21 [heycam]
JG: is it even necessary to have that much complexity?
14:05:27 [heycam]
... it's not hard to compute the distance between two points
14:05:31 [heycam]
... and it's not always what you want
14:06:07 [heycam]
CM: I'd like to see if something more general than for ports/connectors and script layout would be good for this use case
14:06:16 [heycam]
JG: what might be useful is computing the closest points between two curves
14:06:24 [heycam]
CM: that would be nice to have
14:06:36 [heycam]
DD: there are lots of times you would want two edges to share a port as well
14:06:46 [heycam]
DS: I did make consideration for whether a port could only hold one connection
14:07:12 [heycam]
... just throwing stuff out for API ideas
14:07:24 [heycam]
... wrote my script library two years ago, but it didn't have sophisticated layout stuff
14:08:01 [heycam]
... so rather than get in to specifics, we should look into an API so that script could plug in and perform layout
14:08:35 [heycam]
TB: I looked briefly at what Dia does
14:08:55 [heycam]
... Inkscape algorithms do move the arrows from the center, by the way
14:09:08 [heycam]
... one difference in Dia is that you can specify a Bezier, quadratic or cubic, to connect the shapes
14:09:10 [heycam]
DS: automatically?
14:09:13 [heycam]
TB: you pick
14:09:21 [heycam]
DS: but you don't say what the path is, you just say "I want a cubic"?
14:10:29 [heycam]
TB: you can control it
14:10:56 [heycam]
DS: if we're going to have an API for layout, one piece of metadata you might want to have is the weight
14:11:00 [heycam]
... ascribing a weight to a line
14:11:47 [heycam]
... could be useful for the script implemented layout algorithms
14:12:52 [heycam]
DD: maybe even a vector of numbers, rather than scalars
14:18:03 [heycam]
DS: if the attribute isn't processed, then it can contain any value, including a vector
14:18:32 [heycam]
... when I suggested adding a connector element, cyril suggested adding this functionality to path, so that it could be used as a fallback
14:18:45 [heycam]
CC: can't remember saying that, but it would help with backwards compatibility
14:18:55 [heycam]
JG: and having attributes to identify the start/end node
14:19:04 [heycam]
CC: if the browser does not understand the behaviour it should understand the rendering
14:19:40 [heycam]
DD: some of this edges have a default geometry which is shortest line between centroids, which means there is not always some path geometry
14:22:00 [heycam]
RL: if you add more attributes to path, you're just adding a drag on when path is used and not used
14:23:33 [heycam]
... DOM node size in memory would increase
14:23:37 [heycam]
CM: what about child elements to specify this?
14:23:41 [heycam]
DS: feels unnatural
14:23:58 [heycam]
TB: you can use a switch element for backwards compatibility
14:24:10 [heycam]
DS: and if you're using script, you can just detect whether connectors are supported
14:24:25 [heycam]
DD: one API people might want is to have automatic graph rendering
14:24:37 [heycam]
... suppose a user builds a graph, and they don't want to lay out the coordinates of anything, not even the nodes
14:24:46 [heycam]
... or they've only laid out the geometry of the nodes
14:24:53 [heycam]
... we'd assume that lines would automatically do the routing
14:25:00 [heycam]
DS: I think we don't want to do automatic routing, or layout of nodes
14:25:22 [heycam]
... but what if there was a layout=auto and the UA could do whatever it wanted with the layout
14:25:44 [heycam]
RL: the inconsistency in rendering would be too much of a problem
14:30:25 [heycam]
ACTION: Doug to add a weight attribute to the connectors spec
14:30:26 [trackbot]
Created ACTION-3144 - Add a weight attribute to the connectors spec [on Doug Schepers - due 2011-10-27].
14:30:56 [heycam]
ACTION: Add attribute for auto straight/curved lines between nodes to the connectors spec
14:30:56 [trackbot]
Sorry, couldn't find user - Add
14:31:01 [heycam]
ACTION: Doug to Add attribute for auto straight/curved lines between nodes to the connectors spec
14:31:01 [trackbot]
Created ACTION-3145 - Add attribute for auto straight/curved lines between nodes to the connectors spec [on Doug Schepers - due 2011-10-27].
14:34:11 [heycam]
ISSUE: Investigate a script API for listening to object changes to facilitate JS layout more easily
14:34:12 [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 .
14:35:43 [heycam]
RL: I think this is more useful for authoring tools
14:35:56 [heycam]
... in terms of browser implementation, I think there are more things important to implement
14:36:05 [heycam]
... but to get authoring tools to interoperate I think that would be higher on their priority list
14:36:21 [heycam]
DS: I think giving people some behaviour in browsers for free will promote the use of this more
14:36:29 [heycam]
... I'm trying to make very minimal additions to what the browsers would have to support
14:37:34 [heycam]
Topic: Meshes
14:40:06 [heycam]
ISSUE: Polylines and maybe other elements might support rounded linejoins, like rx/ry for rects
14:40:07 [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 .
14:41:41 [heycam]
CM: tensor control points on the meshes, how useful would they be?
14:41:46 [heycam]
TB: it would be useful for pdf import at least
14:43:25 [heycam]
TB: cairo supports it
14:45:34 [heycam]
[tav draws an example of a patch with tensor points]
14:47:39 [heycam]
[issue with having to specify otherwise missing stops just to give the tensor point]
14:48:12 [heycam]
... another issue do you allow different colours instead of using previous colours defined at intersection points of patches
14:51:27 [heycam]
... PDF allows mesh patches to share edges in whatever order and position
14:52:08 [heycam]
CC: so you would need to use one mesh per PDF patch, would result in a lot of output when converting
14:53:15 [heycam]
CM: wonder if PDF allows points to have different colours on different sides
14:54:12 [heycam]
CC: you could just have a zero size patch in between
14:54:40 [heycam]
CM: it's probably not as useful for realistic looking images
14:56:04 [heycam]
JG: so if PDF already allows strange patch ordering, it will be expensive to convert to SVG
14:56:19 [heycam]
... if you do exactly what PDF does ...
14:56:23 [heycam]
TB: it's not good for editing
14:56:47 [heycam]
JG: if you extend that not just to share one edge, but more than one edge
14:57:06 [heycam]
CC: so start with something PDF-like, and add the ability to specify which edges are shared
15:03:45 [heycam]
JG: if we do allow just a grid, and allow that grid edges not be shared, then effectively you can draw whatever you want
15:04:47 [heycam]
CC: I'm fine with going with a grid, but I'd like to see some tests
15:05:14 [heycam]
... some examples of grids built with an authoring tool, and some made by other means maybe vectorisation tools
15:05:47 [heycam]
TB: I saw one once where you specify triangles with no order at all, and another with arbitrary points
15:06:27 [heycam]
... I'd like to know why PDF does it like that
15:06:59 [heycam]
ACTION: Gaurav to ask about PDFs using non-grid gradient meshes
15:07:00 [trackbot]
Created ACTION-3146 - Ask about PDFs using non-grid gradient meshes [on Gaurav Jain - due 2011-10-27].
15:07:09 [heycam]
TB: another question is path syntax
15:07:23 [heycam]
... don't know whether you need to include H/h/V/v
15:07:44 [heycam]
... what might be useful is the shortcut curve commands, C/c/S/s
15:09:40 [heycam]
CM: they don't make sense at every patch edge
15:09:48 [heycam]
... you could disallow them in those positions
15:12:48 [heycam]
CC: it does make sense
15:14:04 [heycam]
TB: ah it's not so useful after all, because you're not specifying the mesh grid lines as a whole
15:14:14 [heycam]
TB: what about Q/q/T/t
15:14:21 [heycam]
... trivial conversion but it's probably not worth it
15:17:35 [heycam]
TB: the last issue is arc commands
15:17:41 [heycam]
... the algorithm for filling this expects a bezier
15:17:46 [heycam]
... so you'd need to convert arcs to beziers
15:18:55 [heycam]
... I'm not sure about it
15:19:02 [heycam]
... the authoring tools can handle
15:19:12 [heycam]
CC: so we're introducing a new type, right?
15:19:14 [heycam]
... a new datatype
15:19:19 [heycam]
... the path attribute would have a different datatype?
15:19:30 [heycam]
TB: the form of arc that's used for regular paths is not that friendly
15:21:13 [heycam]
CC: what if you have a path with arc commands and you want to fill it with a gradient mesh
15:27:33 [heycam]
... now what about the new path commands, catmull-rom and turtle graphics?
15:27:46 [heycam]
CM: if you are disallowing arcs, you should disallow catmull-roms
15:28:09 [heycam]
... at maximum, include ones that convert into exactly one bezier
15:28:52 [heycam]
JG: I know in Inkscape it would be easy to reuse the existing path reading code
15:29:23 [heycam]
RL: it wouldn't be hard to have a flag on the path data reader
15:31:22 [karl]
karl has joined #svg
15:33:41 [heycam]
[discussion about which commands to allow]
15:36:14 [heycam]
CM: z feels a bit funny to me, since it goes to the end point instead of the start point of the patch path
15:37:48 [heycam]
CC: if you leave off a Z, it's like you put a Z anyway yes?
15:37:51 [heycam]
CM: that would make me happier
15:42:21 [heycam]
someone: do we need letters at all?
15:44:08 [heycam]
RESOLUTION: We allow just C/c/L/l in mesh path data
15:50:12 [heycam]
RESOLUTION: We will leave out tensor control points from gradient meshes
15:51:05 [heycam]
RESOLUTION: We will not allow multiple colours at mesh intersections, just use zero size patches instead
15:51:56 [heycam]
ACTION: Tav to update the mesh gradients page with these resolutions
15:51:56 [trackbot]
Created ACTION-3147 - Update the mesh gradients page with these resolutions [on Tavmjong Bah - due 2011-10-27].
15:56:06 [heycam]
CC: There's a document called Advanced Gradients Requirements, Anthony was editing it
15:56:13 [heycam]
... someone asked me to do some fixes to it
15:56:35 [heycam]
... I'll make those edits
16:00:04 [tbah]
http://tavmjong.free.fr/SVG/SCHILLER/html.html
16:03:51 [heycam]
Topic: inconsistencies between implementations on viewports and overflow
16:05:25 [heycam]
TB: so what do we do about this?
16:05:31 [heycam]
jwatt was looking into it
16:05:51 [heycam]
CM: let's make these proper SVG tests for the Integration spec
16:07:28 [heycam]
https://bugzilla.mozilla.org/show_bug.cgi?id=611099
16:09:03 [heycam]
ED: the intrinsic sizing fixes in 1.2T got ported over to 1.1SE
16:10:34 [heycam]
RL: current mozilla thoughts from jwatt on how to resolve the issues https://bugzilla.mozilla.org/show_bug.cgi?id=668163#c27
16:15:17 [heycam]
ACTION: Doug to tell Cameron what is wrong with the table generating scripts for Integration
16:15:18 [trackbot]
Created ACTION-3148 - Tell Cameron what is wrong with the table generating scripts for Integration [on Doug Schepers - due 2011-10-27].
16:17:04 [heycam]
ACTION: Cameron to contact jwatt about SVG sizing to summarise his thoughts so we can talk to CSS at TPAC
16:17:05 [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].
16:17:32 [tbah]
tbah has joined #svg
16:20:30 [heycam]
Topic: longsonr's annoyances
16:20:36 [heycam]
RL: upper limit for numOctaves
16:20:48 [heycam]
... I think Opera has a limit
16:21:01 [heycam]
CM: and I think IE mentioned he limits it to 10?
16:22:45 [heycam]
RL: in some of the attributes, you have integer optional integer
16:22:52 [heycam]
... but there's no type, it's number optional number
16:23:00 [heycam]
... wondering whether it makes sense to have an integer optional integer type
16:24:42 [heycam]
... I'd like it to cause the attribuet to be invalid if numbers are specified in the DOM attribute
16:26:00 [heycam]
JG: I'd be against putting an explicit limit for numOctaves
16:26:10 [heycam]
... it shouldn't make a visible difference where you stop after a while
16:26:15 [heycam]
RL: next, clip
16:26:30 [heycam]
... the meaning of the numbers differs between CSS 2.0 and 2.1
16:26:37 [heycam]
... would be good to align with CSS 2.1
16:28:45 [heycam]
... next, feTurbulence has seed="" which is really an integer, so why not make it one instead of a number and defining rounding
16:29:12 [heycam]
... next, would like to remove the duplicate SVGLoad, SVGAbort, etc.
16:29:30 [karl]
karl has joined #svg
16:30:03 [heycam]
... we should also drop the requirement to dispatch load to every element
16:33:17 [heycam]
... next, overflow:auto on markers
16:33:26 [heycam]
... doesn't make sense in combination with overflow-x/overflow-y
16:33:34 [heycam]
... makes sense in the current firefox implementation, which is opposite to what the spec says
16:35:25 [heycam]
... so I'd like auto to be equivalent to hidden for markers
16:37:53 [heycam]
... next, there's a test with styles on non-containers
16:38:13 [heycam]
... presentation attributes on elements to which they have no effect
16:39:40 [heycam]
... it's a performance problem
16:39:55 [heycam]
... next, are we taking SMIL3's allowReorder into SVG?
16:40:29 [heycam]
... some other SMIL3 things have been requested for SVG
16:40:37 [heycam]
... would be good to go through SMIL3 to find features we want to import
16:42:32 [ed]
[LUNCH]
16:43:54 [ed]
meeting adjourned, we'll discuss the remaining topics at TPAC
16:44:21 [ed]
RRSAgent, make minutes
16:44:21 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/10/20-svg-minutes.html ed
17:22:32 [karlushi]
karlushi has joined #svg
17:25:47 [ed]
trackbot, close telcon
17:25:47 [trackbot]
Sorry, ed, I don't understand 'trackbot, close telcon'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
17:26:26 [ed]
trackbot, end meeting
17:26:26 [trackbot]
Zakim, list attendees
17:26:27 [trackbot]
RRSAgent, please draft minutes
17:26:27 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/10/20-svg-minutes.html trackbot
17:26:28 [trackbot]
RRSAgent, bye
17:27:01 [ed]
RRSAgent, make minutes public
17:27:01 [RRSAgent]
I'm logging. I don't understand 'make minutes public', ed. Try /msg RRSAgent help
17:27:06 [ed]
RRSAgent, make logs public
17:27:10 [ed]
trackbot, end meeting
17:27:10 [trackbot]
Zakim, list attendees
17:27:11 [trackbot]
RRSAgent, please draft minutes
17:27:11 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/10/20-svg-minutes.html trackbot
17:27:12 [trackbot]
RRSAgent, bye
17:27:12 [RRSAgent]
I see 7 open action items saved in http://www.w3.org/2011/10/20-svg-actions.rdf :
17:27:12 [RRSAgent]
ACTION: Doug to add a weight attribute to the connectors spec [1]
17:27:12 [RRSAgent]
recorded in http://www.w3.org/2011/10/20-svg-irc#T14-30-25
17:27:12 [RRSAgent]
ACTION: Add attribute for auto straight/curved lines between nodes to the connectors spec [2]
17:27:12 [RRSAgent]
recorded in http://www.w3.org/2011/10/20-svg-irc#T14-30-56
17:27:12 [RRSAgent]
ACTION: Doug to Add attribute for auto straight/curved lines between nodes to the connectors spec [3]
17:27:12 [RRSAgent]
recorded in http://www.w3.org/2011/10/20-svg-irc#T14-31-01
17:27:12 [RRSAgent]
ACTION: Gaurav to ask about PDFs using non-grid gradient meshes [4]
17:27:12 [RRSAgent]
recorded in http://www.w3.org/2011/10/20-svg-irc#T15-06-59
17:27:12 [RRSAgent]
ACTION: Tav to update the mesh gradients page with these resolutions [5]
17:27:12 [RRSAgent]
recorded in http://www.w3.org/2011/10/20-svg-irc#T15-51-56
17:27:12 [RRSAgent]
ACTION: Doug to tell Cameron what is wrong with the table generating scripts for Integration [6]
17:27:12 [RRSAgent]
recorded in http://www.w3.org/2011/10/20-svg-irc#T16-15-17
17:27:12 [RRSAgent]
ACTION: Cameron to contact jwatt about SVG sizing to summarise his thoughts so we can talk to CSS at TPAC [7]
17:27:12 [RRSAgent]
recorded in http://www.w3.org/2011/10/20-svg-irc#T16-17-04