Some keys in the topaths library do (still) not get parsed

[marmotghost]

There are at least keys, in and out, in the topaths library which do not get parsed. To see what the problem is, uncomment the commented part in the code below.

\documentclass[tikz,border=3mm]{standalone}
\begin{document}
% \begin{tikzpicture}
%  \draw (0,0) to[out={3*(4+1)},in=160] (2,0);
% \end{tikzpicture}
\makeatletter
\tikzoption{out}{\pgfmathsetmacro\tikz@to@out{#1}\tikz@to@switch@on}
\tikzoption{in}{\pgfmathsetmacro\tikz@to@in{#1}\tikz@to@switch@on}
\makeatother
\begin{tikzpicture}
 \draw (0,0) to[out={3*(4+1)},in=160] (2,0);
\end{tikzpicture}
\end{document}

The suggestion is to replace in tikzlibrarytopaths.code.tex the lines

\tikzoption{in}{\def\tikz@to@in{#1}\tikz@to@switch@on}
\tikzoption{out}{\def\tikz@to@out{#1}\tikz@to@switch@on}

by

\tikzoption{out}{\pgfmathsetmacro\tikz@to@out{#1}\tikz@to@switch@on}
\tikzoption{in}{\pgfmathsetmacro\tikz@to@in{#1}\tikz@to@switch@on}

[ilayn]

I don't have a strong opinion about this whether it is a valid use but might be a compatibility problem

\begin{tikzpicture}
\draw[out=45,in=135] (0,0) to (1,0) (0,0) to (2,0)(0,0) to (3,0);
\path node (a) at (1,1) {} node (b) at (2,2) {} node (c) at (3,3){};
\draw[out=west,in=east](a) to (b) (b) to (c);
\end{tikzpicture}

[marmotghost]

@ilayn One can certainly have both. At the moment, the situation is very confusing, e.g. bend left is getting parsed. Please note that the keys you are referring to are not working as one would expect. To see this, look at

\documentclass[tikz,border=3mm]{standalone}
\begin{document}
\begin{tikzpicture}
\begin{tikzpicture}
\draw[out=45,in=135] (0,0) to (1,0) (0,0) to (2,0)(0,0) to (3,0);
\path[nodes={minimum width=1cm,minimum height=2cm,draw}] 
	node (a) at (1,1) {} node (b) at (2,2) {} node (c) at (3,3){};
\draw[out=north west,in=south east](a) to (b) (b) to (c);
\end{tikzpicture}
\end{tikzpicture}
\end{document}

As you can see, north west is not the north west anchor, but just 135, which may accidentally may coincide with north west. I would suggest to clean this up as well.

[muzimuzhi]

@marmotghost In out=north west, the north west is not a node anchor, but the angle part of a polar coordinate. In this context, north west is defined as 135.

Edit: Well, since most other keys accepting an angle seem to execute the calculation on key value ...

pgf/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex

Lines 5343 to 5347 in 67295ec

	\def\tikz@parse@polar#1(#2:#3){%
	\pgfutil@ifundefined{tikz@polar@dir@#2}
	{\tikz@@parse@polar#1({#2}:{#3})}
	{\tikz@@parse@polar#1(\csname tikz@polar@dir@#2\endcsname:{#3})}%
	}%

pgf/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex

Line 5387 in 67295ec

\expandafter\def\csname tikz@polar@dir@north west\endcsname{135}%

PS: Your example in #947 (comment) has tikzpicture environments nested.

[marmotghost]

@muzimuzhi Yes. My comment was precisely to point out that north west gets interpreted as 135 and not as the true north west anchor of a node.

However, your comment allows one to easily define an improved version of my original request:

\documentclass[tikz,border=3mm]{standalone}
\begin{document}
\makeatletter
\tikzoption{out}{\pgfutil@ifundefined{tikz@polar@dir@#1}{%
	\pgfmathsetmacro\tikz@to@out{#1}}{%
	\def\tikz@to@out{\csname tikz@polar@dir@#1\endcsname}%
	}\tikz@to@switch@on}
\tikzoption{in}{\pgfutil@ifundefined{tikz@polar@dir@#1}{%
	\pgfmathsetmacro\tikz@to@in{#1}}{%
	\def\tikz@to@in{\csname tikz@polar@dir@#1\endcsname}%
	}\tikz@to@switch@on}
\makeatother
\begin{tikzpicture}
 \draw (0,0) to[out={3*(4+1)},in=160] (2,0);
 \path[nodes={minimum width=1cm,minimum height=2cm,draw}] 
	node (a) at (1,1) {} node (b) at (2,2) {} node (c) at (3,3){};
 \draw[out=west,in=east](a) to (b) (b) to (c);
\end{tikzpicture}
\end{document}

This version keeps the behavior as it was but improves it as it allows the user to get the expression parse, which is consistent with, say, the bend left key, which was fixed not so long ago.

And sorry about the nested tikzpictures. (It does not matter in this case, though.)

[muzimuzhi]

In out=north west, the north west is not a node anchor, but the angle part of a polar coordinate. In this context, north west is defined as 135.

Hmmm, here north west is partly interpreted as node anchor, when \tikztostart is a node. For example, see lines 150--151 in

pgf/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex

Lines 141 to 151 in 67295ec

	\def\tikz@to@modify#1#2{%
	\pgfutil@ifundefined{pgf@sh@ns@#1}
	{}%
	{\edef#1{#1.#2}}
	}%
	\def\tikz@to@compute{%
	\let\tikz@tofrom=\tikztostart%
	\let\tikz@toto=\tikztotarget%
	\tikz@to@modify\tikz@tofrom\tikz@to@out%
	\tikz@to@modify\tikz@toto\tikz@to@in%

As a result,

\path[nodes={minimum width=1cm,minimum height=2cm,draw}] 
  	node (a) at (1,1) {} node (b) at (2,2) {};
\draw[out=north west,in=south east] (a) to (b);

is (more or less) equivalent to

\draw (a) .. controls ([shift=(north west:25.07983pt)]a.north west) and 
                      ([shift=(south east:25.07983pt)]b.south east) .. (b);

[marmotghost]

@muzimuzhi Yes. As you say, not the (a.north west) but rather ([shift=(north west:25.07983pt)]a.north west) get used. I agree that this is not the same as (a.135). Anyway, the above proposal does not change the past behavior for working codes, yet makes codes that did not work working.

[hmenke]

This is becoming kind of a whack-a-mole game with parsing options. Is there actually a real benefit here from being able to provide a mathematical expression rather than just a number? Please also let me remind you that the math parser actually has quite some overhead so I don't really think that it's smart to try to parse everything that accepts a number.

[marmotghost]

@hmenke Well, most of the similar keys (like bend left, say, but also xshift and friends) do parse their arguments, so in and out are the exception. While it is very easy to do the parsing on your own, and to feed the result to in or out, users may just get confused when this does not always work. Especially less experienced users may not immediately understand what precisely is the problem.