16

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,

enter image description here

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

enter image description here

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.

  • The arrow heads are probably there but squashed due to the nonlinear transformation, increase the line width for testing – percusse May 25 '18 at 22:43
  • 1
    @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. –  May 26 '18 at 01:08
  • arrow heads are also transformed so don't expect normal heads. – percusse May 26 '18 at 02:07
  • @cfr Thanks. But this does not quite work either. But I agree with your last comment. Interestingly, if you use a different arrow head, it shows correctly, only if you use the same thing again, it does not! And if you use this arrow head in a picture before the one with the nonlinear stuff, it works again! –  May 26 '18 at 02:17
  • 1
    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 02:33
  • 1
    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 02:35
  • 1
    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 02:39
  • @cfr You won't believe how much this drove me crazy here ;-) I absolutely think you're on the right track. (What however not works is if you try to cheat and just pretend to use the arrow in\path[-{Latex}] (0,0) -- (1,0);. TikZ is too clever for that ;-) –  May 26 '18 at 02:41
  • 1
    @marmot What about just putting it in a box but not typesetting the box? – cfr May 26 '18 at 02:52
  • @cfr You're a genius, that works! (Obviously you're much better in cheating than I am ;-) If you want to shoot a partial answer, I'll be happy to accept it. "partial" because the first part of the original question is still open but that can be re-asked. Unlike the arrow part, the first part seems to be sensitive to the transform shape nonlinear=true stuff. –  May 26 '18 at 03:08
  • 1
    It seems you can turn caching off for an arrow tip when declaring it, but not when using it. At least, I can't figure out how to switch it off. I'm sure it is the caching: it's right in the code. (Probably somewhere in the manual, too.) – cfr May 26 '18 at 03:14
  • Isn't the first issue just a known limitation of canvas transformations generally? The manual is quite clear on this: one reason you don't usually want these is that TikZ loses track of the positions of points and sizes. So there isn't a way of picking up those points later, because TikZ doesn't know where they are. – cfr May 26 '18 at 03:58
  • @cfr No, I do not think the first issue is the usual thing. There are no issues with drawing lines to the respective coordinates if they are in scopes with linear transformations or even nonlinear transformations but without transform shape nonlinear=true. One can access the points even in axis environments of pgfplots that way. This is the first time I see this, and I believe this issue is really tied to transform shape nonlinear=true. –  May 26 '18 at 04:09
  • @marmot Then, yes, probably you should ask a new question for that. In essence, you've asked two questions here with the typical problem: you got an answer which addresses one, but not the other. – cfr May 27 '18 at 02:27
  • I'm pretty sure that using a box can't qualify as 'brilliant' in the TeX world. :-) – cfr May 27 '18 at 02:28
  • @cfr Depends how you define TeX world. If you only mean users with more than 600k reputation, perhaps, but for more mundane users it is a really cute trick, I think ;-) –  May 27 '18 at 14:55

1 Answers1

16

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.

cfr
  • 198,882
  • 2
    The buzzword is protocolled for the caching you mentioned. – percusse May 26 '18 at 07: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
  • 2
    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 02:24