In my answer to question improving-tree-diagram i wrongly use forked edges
:
\documentclass[border=3mm]{standalone}
\usepackage[edges]{forest}
\begin{document}
\begin{forest}
for tree={
font=\footnotesize,
draw, semithick, rounded corners,
align = center,
inner sep = 3mm,
edge = {draw, semithick, -stealth},
grow = east,
forked edges, % <-- wrong, it should not be inside scope of "for tree"
l sep = 12mm% level distance
}
[Multimedia\\ RSs
[Multimedia\\ Content]
[Multimedia\\ Content]
]
\end{forest}
\end{document}
which gives:
However, with correct forked edge
instead of forked edges
the result is unacceptable:
It is corrected to first one, if I added to for tree
options:
parent anchor = east,
child anchor = west,
or if I use forked edges
outside of tree, for example:
...
\begin{forest}
forked edges,
for tree={
font=\footnotesize,
draw, semithick, rounded corners,
align = center,
inner sep = 3mm,
edge = {draw, semithick, -stealth},
grow = east,
l sep = 12mm% level distance
}
...
I wonder, why the forked edge
and forked edges
gives different result?
One more question: why the point of the branch of edges is not on the middle of level distance if it is defined, for example l sep=12mm
regardless if parents/child anchors are defined?
I read forest
documentation, but didn't find anything usable about mentioned (maybe I need read it again and again … and also look into code) .
Best Answer
Here are the definitions for
forked edge
andforked edges
fromforest-lib-edges.sty
.So we see that
forked edges
not only appliesforked edge
to all descendants, but adjusts theparent anchor
for the tree and thechild anchor
for the descendants as well.I don't think that
forked edge
is correct here. It is true that you don't wantforked edges
because then you'll havewhich can cause problems.
However, if you use
\forked edge
without setting the parent/child anchors, then Forest defaults to using the(<node>)
itself and TikZ then selects a border anchor in its usual way. However, the initial part of the forked path is drawn relative to the starting point. The starting point is also(<node>)
but this time TikZ is measuring relative to rather than tracing a path from. So rather than using the node's border anchor, it uses the node's default anchor, which is.center
by default.So although the path starts from the appropriate border anchor, its initial segment takes it towards a location measured relative to the
.center
anchor and not measured relative to the border anchor.Here's a visualisation:
The path starts from
(a.east)
, which is right, but the point++(.5em,0)
from(a)
is measured from(a.center)
. This is shown in red. The first part of the path, therefore, is the part shown in blue which is not.5em
, of course. The remainder of the path is then in green.We can see the same thing in the default growth direction where the edge takes
rotate=-90
.I don't understand your second question. Why should
l sep
affect the branching point? I think you are asking why you don't get something like the following.This can be done by adjusting
fork sep
.But note also, that
l sep
is a minimum distance between the closest border point of the parent and the closest border point of each child. That distance may end up being larger than the specified dimension. Forest just stops it being any smaller. (Unless it is altered later, of course, either for the whole tree or more locally.)So you can't guarantee the midpoint in this way. To do that, you would need to alter
fork sep
later, as the tree is packed because you'd need, I think, to change it for each level before the sub-trees of the nodes on that level are packed. (Or you'd have to repack afterwards.) I'm not certain of this, however - it might be sufficient to do it after the entire tree is packed, at least in many cases. (Of course, you'd want to do it before the x and y values are computed.)