This is a hack. It is provided as is. There are no guarantees. I don't even guarantee that it has anything to do with forest, multiline nodes or TeX. At this point, in case it is not clear, I should state that I guarantee nothing whatsoever. If the code dials the CIA, MI5 and the KGB and offers them your cat in exchange for a tube of Smarties, don't say I didn't warn you.
Caveat emptor...
Here's the idea:
If we put a tabular into a node in a tree which does not use align to create multiline nodes, we get just the same results as we do using align. However, tabular itself doesn't add vertical space, so we can't set that space to 0 as it is already zero.
If we put a minipage into a node in the same tree, the spacing is the same as putting the contents of the minipage in the node alone. (Assuming the node has only one line.)
So, if we could create multiline nodes as minipages rather than tabulars, then it would work as desired. (Whether what is desired is desirable is left for you to determine, gentle reader.)
This is not as straightforward as it sounds because a minipage, unlike a tabular requires a width and we don't want to have to set a width for all nodes in the tree.
Surely, there are easier ways to do this and doubtless there are far more efficient ones. Especially a TeX guru would likely do this far better.
At this point, the gentle reader is urged to review again the statement above concerning guarantees and the danger to the cats of all readers, however gentle.
We start by creating a new style squat multiline for trees of this kind:
\forestset{
squat multiline/.style={
We need a couple of custom forest options:
declare dimen={thiswidth}{0pt},
declare autowrapped toks={thiscontent}{},
Now we start manipulating the nodes. We do this in cycles to ensure that each set of keys are processed for each node before the next set of keys is processed for each node.
for tree={
delay={
This is round one:
thiscontent/.wrap pgfmath arg={##1}{content()},
In effect, this saves the content of the node. It copies it, basically. We delay this else the content won't be set when we try to copy it.
},
Now for the next round:
delay+={
content/.wrap value={\begin{tabular}{@{}c@{}}##1\\\end{tabular}},
This wraps the content in a tabular environment like that used by align=center. We are going to use this to get the width for the minipage.
typeset node,
We typeset the node now, earlier than usual, because we need to get the width next.
},
The final round:
before typesetting nodes={
We set thiswidth using the width of the node as it currently is.
thiswidth/.wrap pgfmath arg={##1}{int(abs(max_x()-min_x()))},
Now we reset the content of the node in a minipage of width thiswidth. We use the copy of the contents from thiscontent because otherwise we'll get the tabular wrapper as well.
content/.wrap pgfmath arg={\begin{minipage}[t]{\dimexpr\forestove{thiswidth}}\centering ##1\end{minipage}}{thiscontent()},
We've already got one lot of inner xsep because it was included when we typeset the node originally. So we set it to 0 to avoid getting double the usual amount:
inner xsep=0pt,
We need to tell forest to typeset the node again:
typeset node,
},
Just the usual anchors from the original example:
parent anchor=south,
child anchor=north,
},
}
}
Now we can use the new style. The first example compares the default spacing with that used by squat multiline when the content of the nodes are identical:
\begin{forest}
for tree={draw}
[, phantom
[A, for tree={parent anchor=south, child anchor=north}
[B]
[C
[D]
[E]
]
]
[A, squat multiline
[B]
[C
[D]
[E]
]
]
]
\end{forest}
Then the example with larger nodes and a roof:
\begin{forest}
for tree={draw},
squat multiline
[A,
[B\\long node]
[C
[D\\long multiline, triangle]
]
]
\end{forest}
The style does not appear be responsible for the slight misalignment of the roof here as I get the same issue when I compare the default style with drawn nodes.
Comparison:
In any case, I assume that the combination of a roof and draw is unlikely to be desirable, and the misalignment is only noticeable because the nodes are drawn for purposes of illustration.
Complete code:
\documentclass[multi,tikz,border=10pt]{standalone}
\usepackage{forest}
\begin{document}
\forestset{
squat multiline/.style={
declare dimen={thiswidth}{0pt},
declare autowrapped toks={thiscontent}{},
for tree={
delay={
thiscontent/.wrap pgfmath arg={##1}{content()},
},
delay+={
content/.wrap value={\begin{tabular}{@{}c@{}}##1\\\end{tabular}},
typeset node,
},
before typesetting nodes={
thiswidth/.wrap pgfmath arg={##1}{int(abs(max_x()-min_x()))},
content/.wrap pgfmath arg={\begin{minipage}[t]{\dimexpr\forestove{thiswidth}}\centering ##1\end{minipage}}{thiscontent()},
inner xsep=0pt,
typeset node,
},
parent anchor=south,
child anchor=north,
},
}
}
\begin{forest}
for tree={draw}
[, phantom
[A, for tree={parent anchor=south, child anchor=north}
[B]
[C
[D]
[E]
]
]
[A, squat multiline
[B]
[C
[D]
[E]
]
]
]
\end{forest}
\begin{forest}
for tree={draw},
squat multiline
[A,
[B\\long node]
[C
[D\\long multiline, triangle]
]
]
\end{forest}
\end{document}
Best Answer
This is a solution. The documentation is rather misleading since it isn't true the the value of
anchoronly matters when the node has a sibling.[However, it is not saying what my earlier version of this answer claimed. So if you read that, I was being an idiot and you should ignore it.]
The default value of
caligniscenterwhich aligns the parent'sanchorwith the midpoint between the children'sanchors. And the default value ofanchorisbase.Here's a picture:
So the alignment we'd like requires either changing the
anchorof the parent and children or using a non-default value forcalign.In the first case, we could do something like this, setting
anchor=centerfor the tree:or
anchor=parent(i.e.westin this case):or
anchor=children(i.e.east) here:The anchor
childrenalways faces the children of the node (or where the children would be);parentfaces the parent of the node (or where the parent would be).Alternatively, we could alter
calign. For examplecalign=edge midpoint. However, this doesn't work quite as I expected:I can't figure out exactly where the children's child anchors are in this case but they seem to be wherever-TikZ-would-take-a-path-to relative to wherever you are comping from or going to.
But even setting
parent anchor=eastandchild anchor=westfor the tree doesn't really help:So I would change
anchorfor the tree, as I do below, regardless of what else seems desirable. This seems to give good results in this case.(However, for non-circular nodes, something other than
centerdoes often make sense.)I've also make a couple of other tiny modifications which you may (or may not) be interested in. In particular, I've changed the anchors so that they are not direction-dependent. So you can change the direction of growth and the
parentandchildanchors should still make sense. I've also had the package figure out whether the labels on the edges should go above or below the lines.But only
is really making any difference to the result.
Code for demos: