On 08/05/2013 12:13 PM, Tavmjong Bah wrote:
On Mon, 2013-08-05 at 17:46 +1000, Michael Wybrow wrote:
On 31/07/2013, at 5:20 AM, Sebastian Götte <jaseg@...2974...> wrote:
I will remove any logic from connector-context responsible for handling anything but two endpoints (if you want to draw a connector with multiple "stops", just chain together multiple connectors) and remove the "snap connector end point to connector's intersection with destination shape outline"-logic since I do not think this is too useful.
Do you mean the functionality that adjusts the endpoint of a connector to stop at the intersection with the destination shape? If so, the reason for this is that the arrowhead is drawn at the end of the connector and people frequently want this to coincide with the edge of the shape.
I removed that because it would have been even more work porting and because with the addition of SPPoints it is not really necessary anymore (I am not totally against re-adding it, though).
Do you mean that by placing a Point on the boundary at a particular position the arrowhead will be positioned there? If so, my experience is that people often want connectors that appear to be connected to the centre of shapes, but that are drawn just to the edge of the shape. Manually positioning points in the right place to achieve this effect could get very tedious indeed, especially when moving shapes around.
Yes, that is what I mean. You bring up an interesting point. I don't think it has been explicitly considered in the SVG Connector's spec but I don't think it would be hard to add. What has been considered is that an object can have a set of connecting points that belong to the same class. A connector could be directed to attach to the most convenient (e.g. closest) connector point.
I think this might be too complex. It works fine for e.g. points on a circle, but the distance calculation gets messy as soon as more complex routing (libavoid-style) and concave shapes or even shapes that have holes are involved. I think the problem will be to properly define the behavior in all such fringe cases so another implementation of the routing algorithm in say, javascript running in a browser, may produce consistent results.
A discrete, small set of points also is not sufficient to represent the case where it is in fact irrelevant where the connector attaches (e.g. on a circle).
A complex solution would be to generalize from sets of points to sets of points and curves, but this still does not account for the asethetic factor of the connector's angle to the shape outlines's normal vector. A "more convenient" solution by some simple metric (e.g. euclidean distance) will look bad in some cases. I don't think it is within the scope of an SVG extension to stanardize this. I would prefer an interface that lets the user do all that high-level (aesthetic) reasoning and lets the user to select the best solution for a particular situation.
Sebastian