Here are the definitions for forked edge
and forked edges
from forest-lib-edges.sty
.
\forestset{
declare dimen={fork sep}{0.5em},
forked edge/.style={
edge={rotate/.pgfmath=grow()},
edge path'={(!u.parent anchor) -- ++(\forestoption{fork sep},0) |- (.child anchor)},
},
forked edges/.style={
for tree={parent anchor=children},
for descendants={child anchor=parent,forked edge}
},
}
So we see that forked edges
not only applies forked edge
to all descendants, but adjusts the parent anchor
for the tree and the child anchor
for the descendants as well.
I don't think that forked edge
is correct here. It is true that you don't want forked edges
because then you'll have
for tree={
for tree={
...
which 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
.
\begin{forest}
forked edges,
for tree={
font=\footnotesize,
draw,
semithick,
rounded corners,
align = center,
inner sep = 3mm,
edge = {semithick, -stealth},
grow = east,
l sep = 12mm,
fork sep=6mm,
}
[Multimedia\\ RSs
[Multimedia\\ Content]
[Multimedia\\ Content]
]
\end{forest}
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.)
\documentclass[border=10pt,multi,tikz]{standalone}
\usepackage[edges]{forest}
\begin{document}
\begin{tikzpicture}
\node [draw] (a) at (0,0) {a};
\node [draw] (b) at (1,.25) {b};
\node [draw] (c) at (1,-.25) {c};
\foreach \i in {b,c}
{
\draw [rotate=0] (a) -- ++(.5em,0) |- (\i);
\draw [rotate=0, green] (a) ++(.5em,0) |- (\i);
\draw [rotate=0, blue] (a) -- ++(.5em,0);
}
\draw [red] (a.center) -- ++(.5em,0);
\end{tikzpicture}
\begin{tikzpicture}
\node [draw] (a) at (0,0) {a};
\node [draw] (b) at (-.25,-1) {b};
\node [draw] (c) at (.25,-1) {c};
\foreach \i in {b,c}
{
\draw [rotate=-90] (a) -- ++(.5em,0) |- (\i);
\draw [rotate=-90, green] (a) ++(.5em,0) |- (\i);
\draw [rotate=-90, blue] (a) -- ++(.5em,0);
}
\draw [rotate=-90, red] (a.center) -- ++(.5em,0);
\end{tikzpicture}
\begin{forest}
forked edges,
for tree={
font=\footnotesize,
draw,
semithick,
rounded corners,
align = center,
inner sep = 3mm,
edge = {semithick, -stealth},
grow = east,
l sep = 12mm,
fork sep=6mm,
}
[Multimedia\\ RSs
[Multimedia\\ Content]
[Multimedia\\ Content]
]
\end{forest}
\end{document}
Since you not provide code for your tree, I use some my tree:
\documentclass[border=3mm]{standalone}
\usepackage[edges]{forest}
\begin{document}
\tikzset{every label/.style={xshift=-4ex, text width=6ex, align=right,
inner sep=1pt, font=\footnotesize, text=red}}
\begin{forest}
for tree={ % style of tree nodes
font=\footnotesize,
draw, semithick, rounded corners,
align = center,
inner sep = 2mm,
% style of tree (edges, distances, direction)
edge = {draw, semithick, -stealth},
parent anchor = east,
child anchor = west,
grow = south,
forked edge, % for forked edge
l sep = 12mm, % level distance
fork sep = 6mm, % distance from parent to branching point
}
[Multimedia\\ RSS,label=1
[Multimedia\\ Content,label=1.1]
[Multimedia\\ Content,label=1.2.3.4]
]
\end{forest}
\end{document}

Best Answer
The packing system does not take account of edge labels, as explained on page 33. So the simplest way to do this is to adjust the minimum distance between levels (
l sep
) and/or the minimum distance between siblings (s sep
) by hand.For example, adding
s sep+=50pt
andl sep+=50pt
to an expanded style,ew edges new
, produces the following tree:Alternatively, it is possible to override the packing mechanism's decisions. To do this, you need to make adjustments after the packing stage but before the final positions are calculated. This can be done, for example, using
before computing xy
. Using a new stylemy edge label
to adjust the distance between levels, for example, you can obtain a tree such as this:This does require you to specify the edge label in a different way. Rather than specifying it using
edge label
directly, you need to usemy edge label
. (Obviously, you can use a different name - but you can't useedge label
.) This is necessary because the new style manipulates the label to measure its width. This is then used to calculate an appropriate distance between the levels using Pythagoras' theorem.Note that this second method cannot deal with labels which are too long because the dimensions involved in the calculation become too great. If you need to accommodate really long labels, you should probably adjust the calculation to minimise the sizes of the dimensions involved.