Here is my code and I will post a picture showing what it generates. I will manually draw in red where I would like to draw a line from. I am producing a family tree and I need to connect lines from one person to another. Could anyone help me get this fixed? I want to draw a line from node (kid 1) to node (kid 2), but I want the line from node (kid 1) to originate from the bottom center, not from the right as it is doing. DESPITE EXPLICITLY GIVING SOUTH:8, the line starts from the east side (or right side) of the node.
NOTE: Due to the vastness of these trees, I have to compartmentalize them, meaning there are going to be several different tikzpicture environments, hence the overlay lines in a separate tikzpicture environment.
REASONS:
- Adjust sibling distance
- Adjust level distance
- Move various trees (families) around (scope provides this functionality)
The scope functionality is great for moving things around, but does not give me the flexibility to squeeze trees together when possible—as far as I know (ie some families are smaller than others, which means those respective nodes could be placed closer together).
–thanks in advance!
\documentclass[12pt]{article}
\usepackage[landscape]{geometry}
\usepackage{fontspec}
\usepackage{tikz}
\usepackage{tikz-qtree}
\tikzset{font=\small,
every tree node/.style={align=center, anchor=north},text centered}
\begin{document}
\thispagestyle{empty}%suppress page number
\tikzstyle{every picture}+=[remember picture, overlay]
\begin{tikzpicture}[level distance=6cm,sibling distance=6cm,scale=1,]
\Tree
[.Parent
\node[](kid1){Kid 1};
\node[](kid2){Kid 2}; ]
%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{scope}[xshift=9cm,yshift=-6cm]
\Tree
[.Parent
\node(kid3){Kid 3};
\node(kid4){Kid 4}; ]
\end{scope}
\end{tikzpicture}
\begin{tikzpicture}[overlay]
%\draw[->] (kid1.south)--(kid2.south);
\draw[->] (kid1) .. controls +(south:8cm) and +(south:3cm) ..(kid4);
\end{tikzpicture}
\end{document}
Best Answer
I think this question reveals a bug in the
tikz-qtreepackage. I've contacted the author about it and pointed him to this question. I'm confident that he will fix it. In the meantime, here's a temporary solution.To understand the problem, we need to know a little about how
tikz-qtreeworks. It renders a tree in a recursive fashion. Each subtree is actually a whole newpgfpicture. This would normally cause huge problems, except that the code squirrels away the sub-pictures in boxes. Since the position of each subtree depends on its subtrees and siblings, the subpictures' final positions cannot be known when they are constructed. So there's a system for shifting them around afterwards.Where this causes difficulties is with referring to coordinates (nodes) inside the subpictures. The code is quite cunning: it remembers the later transformations and recursively applies them to adjust the apparent node coordinates to its actual node coordinates. So to the user, the fact that there are these subpictures is not at all obvious.
This works well until you start trying to refer to nodes in other pictures. The code for recursively applying transformations bails out at that step saying "This isn't a node in a subpicture of the current picture, we'll let PGF deal with it as it would have done originally.". However, because subpictures get shifted around after they are constructed, PGF gets it wrong about where it is. The correct (perhaps) method would be to recursively apply the shifts up to the root picture of that node and then use the PGF mechanism to relate the root picture to the current picture. That's what my code below tries to do. It might break something else, though.
(Although
tikz-qtree's subpicture stuff is quite sophisticated, this does show - yet again - the dangers of using subpictures. I would therefore recommend you reconsider the necessity of usingremember pictureandoverlay. Can't you put it all in one grandtikzpicturewithscopes for the separate pieces?)To illustrate this, here's a picture of your code (I added one more child to the first tree in testing) with all the various pictures, their origins, and their ancestors indicated. The green dots are where PGF thinks the subpictures are. The green lines indicate the hierarchy. The blue lines show where each child node's subpicture's origin lies (the ones without blue lines are perfectly aligned with their origins, it might be hard to see at this resolution but one blue line actually leaves the picture altogether).
Here's the full code for the above. Within it is a modified version of the routine for figuring out node positions. I've indicated that segment and made it so that it can be just cut-and-pasted without all the rest of the junk around it. However, I'm leaving the junk in because I think it can be quite useful in seeing how this works.
(Oh, and I removed the
fontspecpackage as it wasn't explicitly needed.)On second thoughts, here's the necessary code without the junk.
And here's the result of that: