Bug in TikZ's math and calc with PDFLaTeX and LuaLaTeX : workaround?

We can use calc library inside tikzmath to do calculations with coordinates.

Everything works fine if we want to calculate something like \p3=(0,0)!.5!(2,0); (inside and outside functions). But if we want a rotation like this \p3=(0,0)!.5!90:(2,0); the following happens :

• If we use this kind of calculation in a function and we compile with PDFLaTeX, or LuaLaTeX, all the coordinates are misplaced after that.
• If we do the same calculations outside of function or if we compile with XeLaTex, everything is ok.

Here is a test code:

\documentclass[tikz,border=7pt,convert={density=3500}]{standalone}
\usetikzlibrary{calc,math}
\begin{document}
\begin{tikzpicture}
\draw (0,0) rectangle (1,1);
\tikzmath{
% function supposed to draw (0,0) -- (0,1) in red
function test(\n){ % useless \n parameter
coordinate \p;
\p1 = (0,0); \p2 = (2,0);
\p3 = (\p1)!.5!90:(\p2);
{\draw[red,thick] (\p1) -- (\p3);};
};
% same code outside function : draw (0,0) -- (0,1) in green
coordinate \p;
\p1 = (0,0); \p2 = (2,0);
\p3 = (\p1)!.5!90:(\p2);
{\draw[green,ultra thick] (\p1) -- (\p3);};
test(1);
}
\end{tikzpicture}
\end{document}

Here is the (bad) result compiled with PDFLaTeX (same as LuaLaTeX): Here is the (good) result compiled with XeLaTeX: The question is : Can we work around this bug?

Some remarks :

• The behaviour is very similar to what we can observe in this question. And following the Mark Wibrow's answer, we can suspect a "non nullfont problem". That can happens for example if : is active character producing some output.
• If we call test(1) just after its definition, both lines are misplaced.
• I had to put in test function one useless parameter \n because we can't have functions without parameter in tikzmath. This is, for me, a strange behaviour.
• I checked the number of <blank space> and \nullfont strings in the log file (with \tracingcommands=1) and it's exactly the same either with pdflatex or xelatex. – egreg Jan 16 '15 at 21:21
• @ereg thanks for checking this! So any idea what's happening here? – Kpym Jan 16 '15 at 21:24
• Driver problem, I'd say. Are you sure the syntax is officially supported? – egreg Jan 16 '15 at 21:26
• @egreg as far as I know there is no exactly such example in the manual. But the manual says that we can use calc inside tikzmath and the syntax is valid calc calculation. And it works as expected in some cases. – Kpym Jan 16 '15 at 23:25
• @cfr the return is not mandatory. If you use it, it must be the last executed statement. One reason is that return dont stop the function execution (like in "usual" languages). All statements after the return will be executed too. – Kpym Jan 17 '15 at 7:48

The bug in this case is the calc library where a line in the definition of \tikz@cc@scan@rot is missing a % character at the end which affects the parsing of angles in coordinate calculations, for example, parsing 90:(0,1) in (0,0)!.5!90:(0,1). I don't know why this didn't affect xelatex though.

The corrected definition should read as follows:

\def\tikz@cc@scan@rot#1{%
\pgfutil@ifnextchar({%)
\tikz@scan@one@point#1% normal
}%
{% <- this was missing
\def\tikz@cc@scan@rot@cmd{#1}%
\ifnum\the\catcode`\:=\active\relax%
\expandafter\tikz@cc@scan@one@rot@active%
\else%
\expandafter\tikz@cc@scan@one@rot@nonactive%
\fi%
}%
}
• FWIW, this is now Ticket 483 in TikZ's bug tracker. It might take a while before the developers get around to dealing with it. – Harald Hanche-Olsen May 6 '18 at 19:07
• And now the bug is fixed (in the source repository). I don't know how long it takes for the fix to migrate onto CTAN and TeX Live. – Harald Hanche-Olsen May 28 '18 at 20:04