I am working at a quite complicated beamer presentation and at some point I could not manage to use the \spy command of TikZ as desired.

Trying to reproduce the problem, I came up with the following one-frame example (copying an example of the spy library from section 68.1 of the PGF manual):

\usetikzlibrary{backgrounds, decorations.fractals, spy}


    \begin{tikzpicture}[spy using overlays={size=12mm}]
        \draw [decoration=Koch snowflake] decorate { decorate{ decorate{ decorate{ (0,0) -- (2,0) }}}};
        \spy [green,magnification=3] on (0.6,0.1) in node at (-0.3,-1);
        \spy [blue,magnification=5] on (1,0.5) in node at (1,-1);
        \spy [red,magnification=10] on (1.6,0.1) in node at (2.3,-1);


Compiled as such, the magnified regions do not show anything but the coloured background.

Playing around with this code, I noticed that any of the following modifications solves the problem:

  • Put the \usepackage{pgfplots} line after the \usetikzlibrary one;
  • Comment out the \usepackage{etex} line;
  • Do not load the backgrounds library;
  • Load the backgrounds library as last one.

Clearly, the last possibility is well suited for my problem (and I already adopted it for my presentation), but I would like to get a better understanding of what is going on in the code above.

  1. Which role do the packages etex and pgfplots play in the game?
  2. Why, in presence of such a packages, loading the backgrounds library before the spy one causes the magnified regions to disappear?
  3. More in general, why do the order of TikZ libraries in the \usetikzlibrary can matter? I would naively guess that it should not be the case.

Searching around before posting the question, I discovered in this answer a bit about how layers work, but this did not answer exactly my questions.


To produce the single frame in my example, the packages etex and pgfplots, as well as the backgrounds library, are not needed. However, I need them in my presentation.

  • Usually pgfplots ruins things by turning on FPU. The only appearance of eTeX in the manual is about \pgfkeysifdefined. Packages spy and backgrounds both defines the style execute at begin scope and they may overwrite each other. – Symbol 1 Mar 27 '17 at 20:43

Beamer and pgfplots are less relevant to this problem. Here is how it goes wrong

  • Beamer, pgfplots, and TikZ will include PGF, which will include pgfcorelayers.code.tex.

  • pgfcorelayers.code.tex has

  • eTeX has
  • backgrounds has


    this is essentially

  • spy has

Notice that at this point, \pgf@newbox is different from \newbox. And it turns out that \tikz@lib@spybox is the same as \pgf@layerboxsaved@background. So potentially an action on the background layer will clean up the spy box.

Why \tikz@lib@spybox = \pgf@layerboxsaved@background?

In TeX, there are only 255 box register and they are called \box0 through \box255. This is extremely user-unfriendly. So in plain-TeX, Knuth defined a syntax \newbox\mybox. It works as follows:

  • \count14 will count how many boxed are there;
  • \newbox will add \count14 by one, and let \mybox be \count14.

However there is a discrepancy between add and assign and assign and add. This is pretty much like in C language

mybox = count14++;

is different from

mybox = ++count14;

So one should make sure that both \pgf@newbox and \newbox choose the same way.

By the way: Box register assignment is by default (maybe) printed into the log file. If you check the log file you will see something like


and you will know something goes wrong.

Some workaround

  • If you put eTeX before TikZ and pgfplots, both \pgf@newbox and \newbox will be the same and there is no problem. However, this does not work if Beamer calls PGF at the first place.

  • If you put eTeX after TikZ and pgfplots, both \pgf@newbox and \newbox will be the same and there is no problem. However, this does not work if you declare any box using \newbox after eTeX is included.

  • If you put spy before backgrounds, then the spy box is different from the background box. However, if you declare any box after backgrounds using \newbox, it will be the same as the background box.

  • A safe way, to the best of my plain-TeX knowledge, is to include eTeX as early as possible and immediately reassign \let\pgf@newbox=\newbox again.

  • Wow, nice explanation! This required me to deepen more than expected. However, it is still not clear to me why you say that it turns out that \tikz@lib@spybox is the same as \pgf@layerboxsaved@background. If \pgf@newbox is (by accident) different from \newbox, I would guess that the spy box is different from the background one. – Axel Krypton Mar 28 '17 at 9:24
  • I agree to the OP: Nice explanation. As I am no expert in this: Do you consider this behavior being a bug and if yes, do you maybe also have an idea how that could be fixed? – Stefan Pinnow Mar 28 '17 at 10:21
  • The add-on of information was very useful. Just a minor clarification for less expert people like me. The definition of \newbox in etex looks identical to that in plain-TeX, but the \alloc@ macro changes! So, in plain-TeX, \count14 is incremented and then used, while, in etex, \count14 is first used and then incremented. – Axel Krypton Mar 29 '17 at 9:05
  • About the suggestion of restoring \let\pgf@newbox=\newbox by hand, clearly it works. Inspired by your suggestion, I guessed that a \RequirePackage{etex} before the \documentclass statement could fix the problem in my code and it does. Is this one of the special cases mentioned in this answer? – Axel Krypton Mar 29 '17 at 9:06

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.