为什么在引入子图时Graphviz不再最小化边长度

我有一个Graphviz图：

digraph
{
   rankdir="LR";
   overlap = true;
   Node[shape=record, height="0.4", width="0.4"];
   Edge[dir=none];

   A B C D E F G H I 

   A -> B -> C
   D -> E -> F
   G -> H -> I

   Edge[constraint=false]

   A -> D -> G

   subgraph clusterX
   {
      A
      B
   }

   subgraph clusterY
   {
      E
      H
      F
      I
   }
}

这将产生以下输出：

我希望A和D之间的边缘长度最小化，以便节点的排列方式如下：

A B C
D E F
G H I

而不是

D E F
G H I
A B C

如果我删除子图定义，这将按预期工作

为什么Graphviz在引入子图时会在底部放置一个B C？

这并不是说要最小化边长度，特别是因为在本例中，边是用属性

constraint=false

定义的

虽然这不是一个完整的答案，但我认为可以在以下两点中找到：

• 图中节点的外观顺序非常重要
• 将

  rankdir

  更改为

  LR

  包含不可预测（或至少难以预测）的行为，和/或可能仍然存在一两个bug（）

我会尽我所能解释并理解graphviz，但你可能想马上继续阅读Stephen North的以下答案——他们应该知道，所以我会引用其中的一些

---

为什么节点的外观顺序很重要？默认情况下，在自顶向下的图形中，首先提到的节点将显示在以下节点的左侧，除非边和约束导致更好的布局

因此，如果没有集群和

rankdir=LR

，图形显示如下（没有意外）：

到目前为止，一切顺利。但是当应用

rankdir=LR

时会发生什么

伯格写道：

Dot通过正常TB布局处理rankdir=LR，然后旋转 按逆时针方向90度布置（当然，还有搬运 节点旋转、边方向等）。因此，子图1是 在TB布局中定位在子图2的左侧 期望值，然后在旋转后低于该值。如果你愿意 子图1要位于顶部，请将其列在图中的第二位

因此，如果这是正确的，在没有集群的情况下，节点应该如下所示：

G H I
D E F
A B C

A B C
D E F
G H I

事实上，它们确实是这样出现的：

G H I
D E F
A B C

A B C
D E F
G H I

为什么?？斯蒂芬·诺斯回答说：

在某个时候，我们决定从上到下应该是默认值，
即使图形旋转，也会有代码翻转平面 内部边缘

因此，图形是按TB布局的，逆时针旋转，平边翻转：

A D G     G H I     A B C
B E H --> D E F --> D E F
C F I     A B C     G H I

虽然这对于简单的图形非常有效，但当涉及到集群时，情况似乎有所不同。通常在簇内也翻转边（如在

clusterY

中），但在某些情况下，平边翻转并不像人们想象的那样有效。你的例子就是其中之一

为什么翻转这些边时会出现错误或限制？因为使用

rankdir=TB

时，相同的图形通常会正确显示

---

幸运的是，解决方法通常很简单-例如，您可以使用节点的外观顺序来影响布局：

digraph
{
   rankdir="LR";
   node[shape=record, height="0.4", width="0.4"];
   edge[dir=none];

   E; // E is first node to appear
   A -> B -> C;
   D -> E -> F;
   G -> H -> I;

   edge[constraint=false]
   A -> D -> G;

   subgraph clusterX { A; B; }
   subgraph clusterY { E; F; H; I; }
}