# Late time consequences of nonlinear transformations

I am really puzzled about the impacts or side-effects of the nonlinear transformations. Consider the MWE

\documentclass[tikz,border=3.14mm]{standalone}
\usetikzlibrary{arrows.meta}
\usepgfmodule{nonlineartransformations}
\makeatletter
\def\polartransformation{% from the pgfmanual section 103.4.2
\pgfmathsincos@{\pgf@sys@tonumber\pgf@x}%
\pgf@x=\pgfmathresultx\pgf@y%
\pgf@y=\pgfmathresulty\pgf@y%
}
\makeatother
\begin{document}

\begin{tikzpicture} % if you comment this out the arrow heads below will disappear
\draw[-{Latex}] (0,0) -- (1,0);
\end{tikzpicture}

\begin{tikzpicture}
\begin{scope} % p. 234 of the pgf manual
\pgftransformnonlinear{\polartransformation}
\draw[-{Latex}] (0,0) coordinate (r1) -- (3,1) coordinate (r2);
\end{scope}
\end{tikzpicture}

\begin{tikzpicture}
\draw[-{Latex}] (0,0) -- (1,0);
\draw[-{Stealth}] (2,0) -- (3,0); % a different arrow head is not affected
\end{tikzpicture}

\end{document}


It produces, as one would expect,

However, if one comments out the first picture, one gets

The arrows of type Latex are completely messed up. Not only in the picture that uses nonlinear transformations, but also in the next one! On the other hand, the arrow of type Stealth is not affected by this.

NOTE: This version of the question is very different from its original version. @cfr, who answers it, found that there are two separate issues. I have stripped of the part that is not covered by @cfr's brilliant answer, and with her or his permission I'd like to re-ask it.

• @percusse The arrow heads are absent (perhaps small) even in the subsequent tikzpicture, that's what I am wondering about. This is something that I never have had before: some local option of (a scope in) picture A influences another picture. But you're right, if I increase the line width, there is something showing up, but not an arrow head. – marmot May 26 '18 at 1:08
• I think TikZ is being too efficient. I can't find the reference immediately, but I think that something gets done when an arrow tip with certain properties is first used. The result is then reused to save compilation resources. So what should happen is that this feature should either get a special tag within the scope of a problematic transform or the feature should be suspended so that nothing is reused and anything used is thrown away. But that doesn't happen. This is a guess. (I just tested the different arrow head scenario to see if this supported it and then read your comment.) – cfr May 26 '18 at 2:33
• If that's right, I'd say this is a bug, but perhaps it might be passed off as a feature. See what @percusse says. – cfr May 26 '18 at 2:35
• Note that if you change the properties of the arrow, it also works because now you're not reusing it. Say, -Latex and -Latex[length=7mm] will work as expected (outside the scope). – cfr May 26 '18 at 2:39
• @marmot What about just putting it in a box but not typesetting the box? – cfr May 26 '18 at 2:52

## 1 Answer

The second (?) problem concerns the effect of arrow-tip caching. When an arrow tip is first used, it is cached. This is a specific tip e.g. Stealth with such-and-such length and so-and-so width etc. When the same tip is used again, the cached tip is used. This saves compilation resources.

[Thanks to percusse for pointing out that this is an example of 'protocolling', as explained in section 116 of the TikZ manual. I used 'caching' because the code for the arrows code uses 'cache' in naming the relevant keys and I didn't know that the underlying stuff was called 'protocolling'.]

So, if the first time a tip is used, it is outside transformed scope, that tip is never transformed.

If the first time is within a transformed scope, that tip is always transformed.

It is possible to prevent caching when defining arrow tips, but it seems it is not possible to prevent arrow tips which are designed to be cached from being cached. That is, you can switch off caching for a family of arrow tips (by redefining Stealth or defining a new tip StealthX) but you can't switch it off for a particular tip (e.g. for Stealth with so-and-so length etc.), let alone for a particular instance of a tip (e.g. this Stealth with so-and-so length etc.).

If you don't want the tips to be transformed at all and your first use is within a transformed scope, a simple workaround is to first typeset the arrow in a box, without typesetting the box. This will cache the untransformed version and all subsequent instances of this tip will be untransformed.

\newsavebox\untransformedtip
\sbox\untransformedtip{\tikz{\draw [-Latex] (0,0) -- (0,1);}


Note that this must be done for every particular tip you want to treat this way - not just every kind of tip. So if you also want this for -Latex[length=7mm], you need to add this to your box, too, as this is a different tip from -Latex.

If you want tips to be transformed only within the scope of transformations, you could make a copy of the kind of tip you want (e.g. Stealth) under a new name (e.g. StealthX) and just alter the definition so that it is not cached. Then you could use Stealth outside transformed scopes and StealthX inside.

Ideally, I guess the nonlineartransformations and/or arrows.meta libraries should handle this automatically. For example, I guess it should be possible to provide a toggle to switch off use of the tip cache, which could be installed for transformed scopes and removed at their ends.

• The buzzword is protocolled for the caching you mentioned. – percusse May 26 '18 at 7:49
• @percusse Thanks. Should I add that? I used 'cache' because that's what I found in the code i.e. names of keys and so on. I'm really not familiar with the terminology here. – cfr May 26 '18 at 15:36
• Thedescription is in Section 116. – percusse May 26 '18 at 16:32
• @marmot I doubt it. I seem to remember somebody pin-pointing the bug but saying it would be hard to fix. I guess you could try compiling the manual to see .... Also, naming pics in the standard way certainly used to work. It is a clear regression. (And it has probably been regressed for longer than it worked, but work it did initially.) – cfr May 27 '18 at 2:24