The order of execution of options (draw & font), pgfextra, and a node along a TikZ path

Question

This is the third and final post in the line of questioning regarding the order of execution of options, pdfextra code and other elements along a TikZ path. The other posts being this and this.

Consider the following LaTeX manuscript

\documentclass{standalone}
\usepackage{tikz}
\begin{document}
    \begin{tikzpicture}
        \def\x{outside}

        \path[draw=blue,font=\Huge]

                 \pgfextra{  \def\x{inside}
                             \draw (2,2) circle(5pt)
                                   node[anchor=south west]{xtra};}

                 (0,0) node[draw] {\x}
         ;
    \end{tikzpicture}
\end{document}

The manuscript features a TikZ picture. The first action to be executed inside the picture is defining the TeX macro \x to be the string 'outside'. Then a TikZ path is defined with two options: the draw color is set to 'blue', and the font size is set to '\Huge'. The path is composed of two elements: (1) a \pgfextra block. The block redefines the macro \x as the string 'inside'. It then draws a circle and next to it - a node with the display text 'xtra'. (2) A node whose display text is \x's replacement text. The node's outline is drawn.

This manuscript typesets thus:

                                         

Note that the path's font option applied to both the \pdfextra code as well as the node, however the draw options applied only to the node. Why?

One possible theory in answer to this question is that, for whatever reasons, the code is executed in the following order: 1. font option, 2. \pdfextra, 3. draw option, 4. node.

Let's put this theory to the test by moving the \pgfextra element to after the node:

\path[draw=blue,font=\Huge]

     (0,0) node[draw] {\x}

     \pgfextra{  \def\x{inside}
                 \draw (2,2) circle(5pt)
                 node[anchor=south west]{xtra};}
     ;

I expect the node's display text to be 'outside', and the circle's stroke color to be blue. However, I'm only partly right:

                                         

Answer 1

If you look at the source code in tikz.code.tex you find the definition for the code that is executed when \pgfextra is encountered on a path:

\def\tikz@extra{\pgfutil@ifnextchar\bgroup\tikz@@extra\relax}
\long\def\tikz@@extra#1{#1\tikz@scan@next@command}
\let\endpgfextra=\tikz@scan@next@command

Basically, whatever is the argument to \pgfextra is executed immediately and scanning continues. Nothing is done to save or restore any graphic or font properties.

When something like this is executed:

\path [...properties1...] ... \pgfextra { \path [] ...; };

Any property that has been set in properties1 may or may not affect the path inside \pgfextra. It depends on the property, when it is set, whether it is set globally, and possibly some other things that I haven't thought of.

Consider the basic node font (i.e., the font used to typeset a node). This is stored in \tikz@textfont and is initially assigned (effictively) globally like this:

\let\tikz@textfont=\pgfutil@empty

so it contains no value. This means that any text in a node will take the document font. When the font key is used (e.g., font=\Huge) the following key is executed:

\tikzoption{font}{\def\tikz@textfont{#1}}

Now, \tikz@textfont contains \Huge and any node without a specific font will use this value within the current scope. When the font key is used in a node, its value will "survive" until the end of the node. But when the font key is used in a path, its value will survive until the end of the path. Any node which doesn't specify a font should take this value. But, this may or may not happen with things like trees or graphs embedded in a path (if they set up a scope and reset the font then probably not).

That is just for fonts. It may be different for line widths, colors, etc. PGF was implemented over a number of years and different people have been involved. There will be some consistency and possibly some inconsistency, due to:

1. a particular feature requires different functionality
2. strong feelings about what should happen
3. misunderstandings about what already happens
4. some other things I haven't though of

The most important thing is none of this really matters.

Firstly, \pgfextra is not designed for arbitrary code. It is executed immediately without out any thought for what may or may not be expected to happen with any graphic or font properties. In particular, casually bunging a \path inside \pgfextra without using \pgfinterruptpath results in undefined behaviour and an expectation of consistency in this case is somewhat baffling.

Secondly, even if \pgfinterruptpath is used and some properties is inherited and some properties are not, explicitly setting the properties on any path inside \pgfextra is not that hard, particularly since multiple properties can be tied up in styles.

Answer 2

Here is an example demonstrating why your questions are almost always impossible to answer with simple arguments. This one features an expansion delay such that we change the color of a node after it is placed. which is not possible in usual syntax but then possible with abusing and hacking.

\documentclass{article}
\usepackage{tikz}
\def\mymacro{\expandafter\global\expandafter\let\expandafter\pgfsavedstrokecolor\csname\string\color@pgfstrokecolor\endcsname}
\begin{document}
\begin{tikzpicture}
\path[draw=blue,font=\Huge]
     \pgfextra{
     \def\x{inside}\mymacro\show\pgfsavedstrokecolor% <-- look at the log it's black again 
     \expandafter\show\csname tikz@strokecolor\endcsname% <-- this one is still blue
     \draw (2,2) circle(5pt)%
     node[draw,anchor=south west]{xtra}
     % we'll change the color of the node above to red with the next line!!
     \pgfextra{\csname tikz@addoption\endcsname{\pgfsetstrokecolor{red}}}
     node[draw]{xtra2}; %<-- draws red
     }
     (0,0) node[draw] {\x};
\end{tikzpicture}
\end{document}

And on top of this black magic, if you comment out the last \pgfextra both of them are not blue but black. Not because a bug! but because our hack leaves out half of the macros needed for this to work properly. This is what you have been doing and getting confused. There are too many macros to be set/reset to mimic TikZ behavior.

In summary, you can't expect things to work at the low levels without taking extreme precautions such as proper TeX groups and expansion control. That's the whole idea of TikZ frontend such that you don't need to do these yourself. Pausing in the middle of a path and doing nontrivial things require TeX knowledge which is often beyond me and proper order of PDF literals. Otherwise you get voodoo magic as above.

In short, things are not that simple to theorize and as commented there is no execution order until to the very end when things are finally fully expanded.