Issue with the "nop" layout

Hi,

I have a small issue using the "nop" layout: splines seems to not be
computed the same way than with the "dot" layout.

For my project, I want to display a graph, and let the user move boxes.
I first build a graph using the "dot" layout in order to place all the
nodes. Then, I read their positions using ND_coord macros, and draw the
graph. When the user move a node, I recreate a graph, but this time, I set
the "pos" attributes of nodes, and use the "nop" layout. It seems to almost
work, but there is differences in the position given to the splines.

Here is a small DOT file that illustrates the issue:
digraph cfg {
graph [bb="0,0,578,532",splines=spline];
bb_0
[fixedsize=true,height=3.1667,pos="408,418",shape=rectangle,width=4.7222];
bb_1
[fixedsize=true,height=1.4167,pos="408,217",shape=rectangle,width=4.1667];
bb_2
[fixedsize=true,height=1.8056,pos="142,65",shape=rectangle,width=3.9444];
bb_3
[fixedsize=true,height=1.2222,pos="408,65",shape=rectangle,width=2.9444];
bb_0 -> bb_1
bb_1 -> bb_2
bb_1 -> bb_3
bb_3 -> bb_1
}

If I render the graph with (the position written in the DOT file will be
ignored in this case):
dot graph.dot -Tpng -ooutput_1.png

and then (positions will not be ignored):
dot -Knop graph.dot -Tpng -ooutput_2.png

You can see a difference with the splines between bb_1 and bb_3.

How can I prevent this?

At present, the only way is

At present, the only way is to always use neato -n to add the splines. The problem is that dot has a special-purpose spline router that takes advantage of the particular properties of the dot layout, in particular, that nodes are drawn on discrete ranks. The spline router in neato is a general-purpose one. Ideally, we could provide the dot routing in neato -n as an option, or allow dot to accept already placed nodes and just add the edges. Unfortunately, the data structures and algorithm used in dot are very complex and are, to a degree, interwoven throughout the dot layout, so pulling out the dot edge routing is non-trivial. Yes, this suggests poor software design but the initial goal was to optimize dot for memory, time and aesthetics, which tends to lead to tightly coupled code.

OK, thank you very much for

OK, thank you very much for your answer!

Recent comments