5

It seems that merely loading the graphdrawing library can mess up drawing a tree using the standard TikZ syntax. Is there a way to avoid this unwanted effect?

For example:

\documentclass[tikz,border=10pt]{standalone}
\usetikzlibrary{arrows.meta}
\tikzset{
  my tree/.style={
    ->,
    nodes={draw, circle, minimum size = .5cm},
    >=Stealth[],
  },
}
\begin{document}
\tikz [ my tree ]
  \node {$\land$}
  child {
    node {$\lnot$}
    child {
      node {$a$}
    }
  }
  child {
    node {$\rightarrow$}
    child {
      node {$b$}
    }
    child {
      node {$c$}
    }
  };
\end{document}

produces the following, expected result:

expected

whereas

\documentclass[tikz,border=10pt]{standalone}
\usetikzlibrary{arrows.meta,graphdrawing}
\tikzset{
  my tree/.style={
    ->,
    nodes={draw, circle, minimum size = .5cm},
    >=Stealth[],
  },
}
\begin{document}
\tikz [ my tree ]
  \node {$\land$}
  child {
    node {$\lnot$}
    child {
      node {$a$}
    }
  }
  child {
    node {$\rightarrow$}
    child {
      node {$b$}
    }
    child {
      node {$c$}
    }
  };
\end{document}

results in overlapping nodes and an overly compact tree:

overlapping

Is there a way to confine the effects of graphdrawing to pictures which are actually graphs?

The problem is caused by the following line of code in tikzlibrarygraphdrawing.code.tex:

\tikzset{level distance=1cm, sibling distance=1cm}

If I comment this out, then the tree is rendered as expected. A comment for this line of code explains its inclusion thus:

% Patch the level and sibling distances so that gd and plain tikz are
% in sync

But why is the graphdrawing library insisting that plain TikZ must be in sync with it? If this is important, surely the library should configure itself to use the standard TikZ default level and sibling distances, rather than imposing its values on standard TikZ trees? What exactly is the motivation for 'sync'ing them anyway?

It just seems egregious: the library is deliberately interfering with plain TikZ's defaults so that trees using the regular syntax will be deformed. Is this some sort of underhand marketing campaign for the graph drawing libraries? I break your code and then I offer you this great solution for those nasty trees you're having problems with which just so happens to require switching to my new-and-improved syntax?! Hopefully there is a less insidious explanation...?

I suspect this is must be a duplicate, but I can't find it.

  • Which part bothers you the most? In your example it seems some length parameters are modified, is that all? – Symbol 1 Aug 21 '15 at 16:17
  • By the way, due to the nature of PGF-family, you do not need to use a library before \begin{document}. So perhaps you can have \bgroup\usetikzlibrary{foobar}\tikz{\foo bar;}\egroup. – Symbol 1 Aug 21 '15 at 16:25
  • You can even \use libraries inside a tikzpicture. For instance you can put \bgroup\usetikzlibrary{arrows.meta}\tikzset{>=Stealth[]}\node foo bar;\egroup inside a tikzpicture with no library used elsewhere. – Symbol 1 Aug 21 '15 at 16:45
  • 1
    @Symbol1 I think the point is more general. Adding another tikz library shouldn't in principle change code that works in a particular way without that library. – Alan Munn Aug 21 '15 at 17:51
  • @AlanMunn That is what I was thinking, indeed. I had understood that TikZ libraries should be loaded in the preamble. But, even if that's not the case, it should, I would have thought, be possible to do so. – cfr Aug 21 '15 at 21:26
3

I guess I found the answer. (And then I saw your edit.)

In tikz.code.tex, line 1322-1323, there are

\tikzleveldistance=15mm  
\tikzsiblingdistance=15mm

However in tikzlibrarygraphdrawing.code.tex, line18-20, there is

% Patch the level and sibling distances so that gd and plain tikz are
% in sync
\tikzset{level distance=1cm, sibling distance=1cm}

So far these are the only conflicts I found.


You said that

the library is deliberately interfering with plain TikZ's defaults

and this might be true, since graphdrawing library seems not written by Till Tantau. However it also seems to be turned over to Till Tantau in 2011.


Nevertheless, in tikz.code.tex, line 937-938, there is

\tikzoption{node distance}{\def\tikz@node@distance{#1}}
\def\tikz@node@distance{1cm}

Now you see the paradox

  • TikZ use 1cm for \node(b1)[above=of a1]{fooy};.
  • TikZ use 1.5cm for child syntax.
  • graphdrawing library, unfortunately, implement some algorithm whose ability is a superset of the above two. (Layered Layouts.) So it unifies the length parameters.

After all I am not surprised that someday these .defaults and .initials would come to fight with each other. Lastly the manual keep mentioning level distance (69 matches) and sibling distance (41 matches). I interpret it as that the author want us to set the parameters ourselves.

  • (+1) But the whole point of the way the key syntax works is that it is easy to avoid these conflicts. If the library confined itself to setting those keys for its own contexts, there would be no problem. It has no business imposing its defaults on pictures which don't use its environments. Why doesn't it configure its settings within a suitably delimited name space? The keys stuff makes that simple to do, which is why it seems egregious not to! – cfr Aug 22 '15 at 2:15
  • @cfr I am not EECS experts, I can say nothing about those decision. However several months ago I had a chance to write a lecture note with mates. And it turns out to have tikz-cd, \xymatrix, align and even \( with \\ all together. Non-TeXperts might never notice the difference. But once you can distinguish \,, \: and \; you have no fortune to ignore them. – Symbol 1 Aug 22 '15 at 2:27
  • Not sure I follow that but maybe that is just my brain. – cfr Aug 22 '15 at 3:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.