Pointy edges in places where straight edges fit

Help
1

Dot is giving me funny edges sometimes, like the one in bold red:

image
image972×606 162 KB

There’s also a bump on the edge next to the node labelled pyunity.values.abc which just feels sort of awkward. Is there any reason for these funny bumps and spikes?

2

Bug.
Maybe related to dot creates ugly edge instead of simple curve (#2249) · Issues · graphviz / graphviz · GitLab, but maybe not - the graphs are not very similar.
Consider adding to #2249 or creating a new issue. Please include your source, OS, command line, and Graphviz version (dot -V)
If you provide your source, there is an easy expe3riment I’d like to try: removing the two goofy edges and then using neato -n2 (FAQ | Graphviz) to re-layout just those two edges. I wonder if they will still be goofy.

3

Source: https://sketchviz.com/@rayzchen/c0c0f4968aff34bfa620f6d1582600b3 · GitHub
OS: Windows 10
Command line: dot -Tsvg graph.dot > graph.svg
Version: dot - graphviz version 3.0.0 (20220226.1711)

4

Hmmm,

  1. Graphviz 5.0.0 is available for download. It might produce a different (better?) result.
  2. Releases 4.0.0 & 5.0.0 give me different (fewer ziggies) results. Linux also gives different (fewer ziggies) results
  3. Here is a script (for Windows) that will redraw any set of edges you want. No guarantees that the edges will be “better” or even different, but they seem to be in this case. I’m not thrilled by the new routing, but “eye-of-the-beholder” thing.
  • add fix=1 to attributes of any edge you want rerouted. E.g. a -- b [fix=1 style=dotted]
  • use a version of this command line (below).
    • Dot creates augmented output in the dot input language
    • gvpr (https://graphviz.org/pdf/gvpr.1.pdf) deletes the edge pos for every edge with fix==1
    • neato -n2 recreates the edges without a pos value (no route), but does not alter the positioning of any other node or edge (FAQ | Graphviz)
dot pyunity1.gv | gvpr -c "E[fix=='1']{$.pos='';$.lp='';}" |neato -G"splines=true" -n2 -Tpng 
>OO.5.0.0.png

Result on my Windows system:

OO.5.0.0
OO.5.0.03361×1595 866 KB

5

This is a bug, but we don’t know exactly what’s wrong. It appears there could be a sign that is flipped somewhere, for example we coded something like the equivalent of x = x - boxwidth instead of x = x + boxwidth. As you may have noticed already, the spline code is not that easy to read, and there’s some idea of working on more general spline debugging support (i.e. render the control polygon of any spline on demand) before attacking this particular problem. Sorry about the bug.

6

I was able to fix this kind of issues a few time by adding space to the rank separation. So, if we want to find the bug then we should look at the impact of rank space.