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