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