[feanaro]

I remember this issue being raised, I think on the graphviz Discourse, and the graphviz developers responding to it as if it was a hard to solve limitation of graphviz for some reason. But I can't for the life of me remember the details.

[graphviz]

"Very poor" seems harsh, but, yes, it hurts us, too. (That, and text with slightly-off baselines.)

The relevant code starts around https://gitlab.com/graphviz/graphviz/-/blob/main/lib/common/... If this isn't right, maybe somebody can figure out why. Perhaps the loop stops sometimes on the wrong side of the boundary? Anyway, it's equally possible that when the endpoint coord is handed off to a lower level driver, the arrowhead mitering is wrong. There is no question there was once upon time explicit code to try to cope with this problem, at least in the native PSgen, but I can't find it now. Maybe it wore away as waves of open source development washed over it, along with static tables for a bunch of "standard" PS fonts.

For more background, see for example https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/s...

In the worst case, this has to be debugged for all the drivers in https://gitlab.com/graphviz/graphviz/-/tree/main/plugin

No doubt there are more details if anyone can remember them.

[s5806533]

I think I found at some point that the arrows could be made correct -- at least for the SVG rendering in Firefox -- by removing the stroke (stroke-width="0").

[pphysch]

Ostensibly each arrow style graphic would need an explicitly-defined "attach point" at whatever is deemed the "tip", so that the tip can be oriented perfectly in relation to the vertex and edge of the GraphViz graph.

If nothing like that exists, I can see how it would be a very troublesome refactor.

[graphviz]

Oh, that too. Feature interaction is a killer, isn't it.