Re: [graphviz-interest] Question: How to improve cluttered graph layout
"Emden R. Gansner" <[email protected]> Mon, 27 Jan 2014 16:02:22 -0500
| Newsgroups | gmane.comp.video.graphviz |
|---|---|
| Message-ID | <[email protected]> |
On 1/27/14 1:42 PM, Fredo Erxleben wrote:
> 1) the "rankdir" in the cluster seems to be ignored.
> The "High"-node (the triangle) is supposed to go left of the "BootRAM"-node, but whatever I try it
> doesn't (which makes routing far more complicated).
>
The rankdir attribute only works at the root graph level, not within clusters. To get what you want,
add rank=same to the cluster, and use the graph
attribute newrank=true.
> 2) The edge routing is quite ugly in this case. I want the edges to leave and reach the nodes at
> certain ports from certain directions, therefor I specified them, but sometimes the specification
> seems to be ignored.
> I tried routing the splines via "splines = ortho" but it seems to make only one turn at best one
> turn. (Or ignores the directions at which the ports are supposed to be left or arrived at.) In
> general I aim for an edge routing that looks more straight, with sharp turns. I tried using
> "invisible" intermediate nodes to make the routing easier for the tool, but it didn't work out
> well, so I dropped them…
One reason the edge routing is ugly is that the nodes are not well placed, especially for your
compass point specifications. First, I would suggest converting your
record nodes to HTML-like labels. The former have some limitations when used with flat edges. (You
can also use tabs to format them.) I'd also hold off on the
compass points, unless you are sure of the relative node positions or this denotes something
special. I'd also move Core before the cluster. Dot is affected by the
order of appearance. With these changes, you get an input graph like the attached file. The drawing
for this seems pretty good to me.
The implementation of flat edge routing, like the edges from Core to BootRAM, is still not
sophisticated enough, so you will sometimes find edges going way out
of their way. A simple workaround is to reset the pos attribute for these bad edges and then send
the graph through neato -n2 -Gsplines. For example,
dot -Gnewrank o.gv | gvpr -c 'E[$.tail.name=="Core" && $.head.name=="BootRAM"]{$.pos = ""}' | neato
-n2 -Gsplines -Tpdf > out.pdf
Also, your example exposed a strange bug. That dir=back specification on the one edge causes very
bad problems all over the graph.
Emden
_______________________________________________
[email protected]
http://lists.research.att.com/mailman/listinfo/graphviz-interest
o.gv
(text/vnd.graphviz, 2 KB)
digraph {
nodesep = 1
ranksep = 1
Clock[
label = "FPGA clock"
shape = underline
]
Core[ shape=none
margin=0
label=<<table cellspacing="0" cellborder="0">
<tr><td colspan="3">Core</td></tr>
<hr/>
<tr>
<td cellpadding="0" ><table border="0">
<tr><td port="p_clock">clock</td></tr>
<hr/>
<tr><td>reset</td></tr>
<hr/>
<tr><td port="p_ram_data">bootRAM_data</td></tr>
</table>
</td>
<vr/>
<td> </td>
<vr/>
<td cellpadding="4" port="p_ram_address">bootRAM_address</td>
</tr></table>>
]
subgraph cluster0 {
rank=same
High [label="" shape=triangle]
BootRAM [ shape=none
margin=0
label=<<table cellspacing="0" cellborder="0">
<tr><td colspan="3">BootRAM</td></tr>
<hr/>
<tr>
<td cellpadding="0" ><table border="0">
<tr><td port="p_clock">clk</td></tr>
<hr/>
<tr><td port="p_clock_enable1">ce1</td></tr>
<hr/>
<tr><td port="p_clock_enable2">ce2</td></tr>
<hr/>
<tr><td>we1</td></tr>
<hr/>
<tr><td>a1</td></tr>
<hr/>
<tr><td port="p_address2">a2</td></tr>
<hr/>
<tr><td>d1</td></tr>
</table>
</td>
<vr/>
<td> </td>
<vr/>
<td cellpadding="0" ><table border="0">
<tr><td port="p_result1">q1</td></tr>
<hr/>
<tr><td port="p_result2">q2</td></tr>
</table>
</td>
</tr></table>>
]
High -> BootRAM:p_clock_enable1
High -> BootRAM:p_clock_enable2
}
Wishbone[
label = "Wishbone"
]
{ rank=same Core BootRAM }
Clock:s -> Core:p_clock
Clock:s -> BootRAM:p_clock
Core:p_ram_data:s -> BootRAM:p_result2
Core:p_ram_address:s -> BootRAM:p_address2
}