3

What is the cause of the following conflict and how should I resolve it?

The conflict involves a compilation error when a document includes the following elements:

  • TikZ externalisation;
  • a TikZ picture which uses local bounding box/.expanded=\macro, where \macro is empty;
  • a Forest tree using the forked edges style which includes a multi-line node.

If the tree is commented out, the tikzpicture is successfully externalised. If the tree is then uncommented, the code compiles as expected.

However, if the tree is uncommented before the tikzpicture has been externalised, externalisation of the tikzpicture fails. If compilation is allowed to proceed, numerous errors including the term forest result.

Is it simply expected that this will fail if \macro is empty? Why does it matter whether the tree is uncommented or not? Or what the style and content of that tree is?

MNME (compile with pdflatex --shell-escape):

\documentclass{article}
\usepackage[edges]{forest}
\usetikzlibrary{external}
\tikzexternalize
\tikzset{%
   person name/.store in=\personname,
   person name=,
}

\begin{document}

\begin{tikzpicture}
  \begin{scope}[local bounding box/.expanded=\personname]
    \node (-pen) [circle, minimum size=40mm] {};
  \end{scope}
\end{tikzpicture}

\begin{forest}
  forked edges,
  for tree={
    align=center,
  },
  [Root Starts Here
    [Something Else
      [All\\Other\\Things
      ]
    ]
  ]
\end{forest}

\end{document}

Initial failure of externalisation and first couple of forest related errors:

==== 'mode=convert with system call': Invoking 'pdflatex -shell-escape -halt-o
n-error -interaction=batchmode -jobname "prawf-figure0" "\def\tikzexternalrealj
ob{prawf}\input{prawf}"' ========
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) (preloaded format=pdflatex)
 \write18 enabled.
entering extended mode
system returned with code 256

! Package tikz Error: Sorry, the system call 'pdflatex -shell-escape -halt-on-e
rror -interaction=batchmode -jobname "prawf-figure0" "\def\tikzexternalrealjob{
prawf}\input{prawf}"' did NOT result in a usable output file 'prawf-figure0' (e
xpected one of .pdf:.jpg:.jpeg:.png:). Please verify that you have enabled syst
em calls. For pdflatex, this is 'pdflatex -shell-escape'. Sometimes it is also 
named 'write 18' or something like that. Or maybe the command simply failed? Er
ror messages can be found in 'prawf-figure0.log'. If you continue now, I'll try
 to typeset the picture.

See the tikz package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.16 \end{tikzpicture}

? 
! Argument of \forest@referencednodename@stripafter has an extra }.                                                                           
<inserted text>                                                                                                                               
                \par                                                                                                                          
l.29 \end{forest}                                                                                                                             

?                                                                                                                                             
Runaway argument?                                                                                                                             
\relax \fi \if \relax \relax \fi \endcsname                                                                                                   
! Paragraph ended before \forest@referencednodename@stripafter was complete.                                                                  
<to be read again>                                                                                                                            
                   \par                                                                                                                       
l.29 \end{forest} 

<... and so on ...>

  • externalisation is not relevant. You get an error simply with the tikzpicture and the forest code. Your empty local bounding box sets \pgf@sh@ns@ to rectangle and this confuses the test \forest@tikz@parse@node@checkiftikzname. – Ulrike Fischer Nov 22 '16 at 8:55
4

Stripping down OP's MWE even further, we see that the following code produces the same error.

\documentclass{article}
\usepackage{forest}

\begin{document}

\begin{tikzpicture}
  \begin{scope}[local bounding box=]
    \node {};
  \end{scope}
\end{tikzpicture}

\begin{forest}
  []
  \path (.child anchor);
\end{forest}

\end{document}

local bounding box defines a new node with the given name. The given name persists after the end of the scope; in fact, as the shown by the next example, even outside the picture.

\documentclass{article}
\usepackage{forest}

\begin{document}

\begin{tikzpicture}
  \begin{scope}[local bounding box=bla]
    \node {};
  \end{scope}
\end{tikzpicture}

\begin{forest}
  []
  \path (bla.south);
\end{forest}

\end{document}

In the first example above (and the OP's original code), the name given to local bounding box is empty, so forest works in an environment containing an empty node. This wreaks havoc with forest's hack into the tikz's implicit coordinate system: the empty node name in a construction <node name>.<anchor name> is meant to signal the usage of a relative node name, but in the presence of an empty node, it tries to retrieve an anchor of the empty-named node. In the first example above, this is child anchor, which is not defined for non-forest nodes, and so the compilation crashes. (If child anchor in the first example is replaced by, for example, `south˙, the code compiles, although the result is not what it should be.)

To sum up, the original error has nothing to do with externalization, forked edges key of forest's linguistics library, or multi-line nodes. It is a consipiracy of three factors:

  • Giving a node an empty name. This one is the user's fault. Although I'm not sure that tikz documentation makes this explicit, I guess that having a node with an empty name was never the idea. ;-) (Forest actually prevents the user from giving a node an empty name.)

  • The node name given to local bounding box persists outside the scope of the picture. This could be viewed as a tikz bug: for me, the expected behaviour would be to keep the node name outside the scope, but forget about it after the end of the picture. (Not the easiest thing to implement...)

  • Forest and its libraries should not depend on forest's hack into tikz's implicit coordinate system (in fact, the hack can be disabled by package option tikzcshack), but rather use the forest cs explicitely.

  • Thank you. It is a bounding box which is given an empty name, isn't it? Rather than a node? I've been doing this for ages. Sorry about not minimising completely. I thought I'd reduced it, but must have got confused. (It took me 3-4 hours to get it down to the minimal example in the question and I was no doubt quite confused by that point.) It did not occur to me that the name would persist outside the tikzpicture. I assumed that only happened when I specified remember picture. – cfr Nov 22 '16 at 16:04
  • What I don't understand, though, is why the first tikzpicture fails to compile. Why doesn't the failure occur when the tree is compiled? In my original document, they are not even on the same slide. So I'd have expected the tikzpicture to compile OK and be shipped out, and then the tree to fail. – cfr Nov 22 '16 at 16:06
  • That may only happen with externalisation, though. That is, without externalisation, I think the error might only occur when it gets to the tree. At least, that's what I thought was happening last night. (Or it is what I now think I thought.) – cfr Nov 22 '16 at 16:08
  • According to the local bounding box documentation, using it creates a node. And (as I wrote in the answer) I agree that persistence of the name outside the tikzpicture is unexpected. – Sašo Živanović Nov 22 '16 at 16:31
  • The first tikzpicture fails to compile because, when it is being externalized, TeX processes the entire document (in the embedded process), failing on the tree. – Sašo Živanović Nov 22 '16 at 16:32

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.