presence of arrowHead can tilt connection sideways

[denys-duchier]

see http://paste.hskll.org/get/1129

byorgey suggested a workaround: http://paste.hskll.org/get/1131
but one can see the thick line comming out of the end of the arrowHead

the problem can also not be fixed by shortening the arrow leg of the shaft because since the shaft is scaled automatically, we can't know in advance by how much to shorten.

[byorgey]

This is another motivating example for having an arrow-drawing mode which takes an appropriate section of the shaft rather than scaling and rotating the shaft to fit between the gaps and arrowhead. Of course in the general case this is more problematic (it may not even be possible to find an appropriate shaft section in all cases, there may be very bad interaction between shaft direction and arrowhead direction, etc.), but I hope we can come up with something that works well for "sufficiently nice" cases.

[byorgey]

For relevant IRC discussion see http://ircbrowse.net/browse/diagrams?id=16233&timestamp=1393701010#t1393701010

[denys-duchier]

I am thinking that we might want different POLICIES for drawing connections. there is the current policy where the path can be both rotated an scaled. we could have an additional policy that does not allow rotation, but allows both scaling of the whole path and adjusting of the lengths of the 2 end legs.

[byorgey]

Well, even with the second policy we have to allow rotation, e.g. what happens if you specify that ushaft should be used to connect two points which are not on a vertical line? But I agree in principle: we want to add a field to ArrowOpts which specifies the shaft policy. The important difference between the policies, as I see it, is how to allow for the arrowheads, tails, and gaps: (1) use the full scaled and rotated shaft with "floating" endpoints that are moved to accommodate heads, tails, and gaps; or (2) scale and rotate the shaft first and "fix" its endpoints at the "control points" for the arrow, and then adjust for gaps and head/tail by taking a section of the shaft (i.e. chopping some off the beginning and/or end). (1) is more robust, but (2) is sometimes more intuitive.

[denys-duchier]

Well, even with the second policy we have to allow rotation, e.g. what happens if you specify that ushaft should be used to connect two points which are not on a vertical line?

this is why I proposed that the end legs could be independently adjusted. this way you can easily get the end points on the line joining the two desired end points of the connection; then scaling of the whole path can get you to actually overlap the points.

[denys-duchier]

After sleeping over it, I had some ideas; so here is a brain dump, lest I forget.

"connect" was designed for relatively simple arrows, and, for that usage, its policy of auto scaling/rotating is excellent. let's not fix what's not broken.

however, there are many types of technical diagrams that require complex connections with layout requirements not compatible with auto scaling/rotations. this is a different usage and it should be provided through a different api.

my first thought was that I would be happy with a simple way to express zigzag connections, i.e. connections made out of alternatingly horizontal/vertical straight-line segments:

zigzagX L N1 N2 D
zigzagY L N1 N2 D

zigzagX indicates that the first leg (out of N1) should start horizontally, L is a list of Double providing signed magnitudes of displacement for all legs except the last 2. the last 2 are automatically provided and adjusted to reach N2.

my second thought was that zigzag could be obtained as a specialization of a more general:

trailconnect T P N1 N2 D

where T is a trail which is automatically translated so that its initial point coincides with N1, then the trail is automatically extended, according to policy P, to reach N2. example of policies:

• straight-line segment
• XY segments
• YX segments

to be completely general, we could make the policy be a class with a method "finish" that takes a trail and a diagram, and returns the trail extended to reach the diagram. that way, we can vary both the types of extension-segments, but also whether to reach the origin or the border.

maybe, for full generality, there should also be a "start" policy that takes N1 and gives us back the actual point from which to start.

[jeffreyrosenbluth]

A few quick toughts:

1. We definitely need to add the option of taking the appropriate section of the shaft. There are are use cases besides the above that need this.
2. I think trailconnect T P N1 N2 D is still too specialized a function for diagrams-lib. It might make a nice module for diagrams-contrib. Something similiar may be able to be done using a custom arrowhead with a segment (probably a thin rectangle) as part of the head, i'm not sure, but if it is I would be fine adding this style of head to Arrowheads.
3. I'm not 100% sure that this is possible, but I think we should create an option that makes the tail (head) a segment of the same width as the shaft and length as the head (tail). I think this would solve your ushaft problem.
4. There is also the issue of making the arrow stop at the edge of the diagram it points to, but point to the diagrams origin.

[bergey]

How much of this would be addressed if arrow'and friends constructed an arrow with head and tail tangent to the shaft where they meet? That's the behavior I would expect, but of course we could make it one policy among many. I think there's a closed-form solution, by way of the law of cosines, although it's a bit of a nasty cubic equation. Either that or I messed up my algebra.6

[jeffreyrosenbluth]

Isn't this what we do currently?
https://github.com/diagrams/diagrams-lib/blob/master/src/Diagrams/TwoD/Arrow.hs#L464

Anyway it doesn't help with 1) for example and we need 1) to handle 4). Sometimes the user will just want the semantics of the arrowhead and tail displacing part of the shaft vs scaling the shaft to make room for the head and tail. 3) is what I did in the latest commit of the tail branch.

[bergey]

I seem to have misunderstood the issue; it's much clearer now that the pastebin is back up.

[jeffreyrosenbluth]

Yes, the picture makes things clear. I added an example to the arrows tutorial that shows how the ushaft problem can be addressed using lineTail and widths. Both new to Arrowheads and Arrows modules.

[jeffreyrosenbluth]

I'm closing this issue because it is partly handled by the change from headSize to headLength using the lineTail. The remainder is overlap with #151.