7

I'm trying to align two paths using polar coordinates:

\documentclass[tikz]{standalone}

\begin{document}

\begin{tikzpicture}
    \path [fill=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
    \path [fill=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
\end{tikzpicture}

\end{document}

However, they are slightly misaligned:

(The picture below is cropped and zoomed in)

enter image description here

Am I missing, i.e. miscalculating something here?

barbaz
  • 1,379
  • 1
    What a funny coincidence to hear from you first. Just an hour ago I came across your name when learning about tikzlings :). The output is cropped and zoomed to the critical location, it's incomplete. I'm using pdflatex from MacTeX 2018. – barbaz Feb 26 '19 at 15:29
  • 7
    I can not answer, but it does not happen, if you avoid [turn] e.g. \path [fill=blue] (0,0) -- ++(-135:5mm) -- ++(-45:25mm) -- ++(45:5mm) -- cycle; – hpekristiansen Feb 26 '19 at 15:38
  • 5
    It doesn't seem that polar coordinates are the reason since `\documentclass[tikz]{standalone}

    \begin{document}

    \begin{tikzpicture} \path [fill=blue] (0,0) -- ++(-135:5mm) -- ++ (-45:25mm) -- ++ (45:5mm) -- cycle; \path [fill=red] (0,0) -- ++(-135:5mm) -- ++ (-45: 5mm) -- ++(45:5mm) -- cycle; \end{tikzpicture} \end{document}has no such problem. Rather, this might be due toturn`.

     –  Feb 26 '19 at 15:38
  • 1
    @marmot: I was 3 second faster :o) – hpekristiansen Feb 26 '19 at 15:39
  • 1
    @hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.) –  Feb 26 '19 at 15:40
  • Thanks to the both of you, at least that's a workaround. I'll create an issue for turn. – barbaz Feb 26 '19 at 15:51

1 Answers1

8

The problem is this old inaccuracies in PGF pointed long time ago by Mark Wibrow. If we apply its correction of \pgfpointnormalised we obtain a better precision not only for the orthogonal projections but also for [turn].

\documentclass[tikz]{standalone}
\usetikzlibrary{spy}

% use the Mark Wibrow's correction
\makeatletter
\def\pgfpointnormalised#1{%
  \pgf@process{#1}%
  \pgfmathatantwo{\the\pgf@y}{\the\pgf@x}%
  \let\pgf@tmp=\pgfmathresult%
  \pgfmathcos@{\pgf@tmp}\pgf@x=\pgfmathresult pt\relax%
  \pgfmathsin@{\pgf@tmp}\pgf@y=\pgfmathresult pt\relax%
}
\makeatother

\begin{document}
  \begin{tikzpicture}[spy using outlines={circle, magnification=7, size=17mm, connect spies}]

    \path [draw=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
    \path [draw=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;

    \spy on (-45:5mm) in node at (2,-.5);
  \end{tikzpicture}
\end{document}

enter image description here

Kpym
  • 23,002
  • +1: Do you know if this "bug" is officially reported? – Dr. Manuel Kuehner Feb 26 '19 at 17:05
  • 1
    @Dr.ManuelKuehner this is not an easy "bug" because by design \pgfpointnormalised is not supposed to be really precise in direction, but it is designed to really have length 1pt (as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge. – Kpym Feb 26 '19 at 17:15
  • 2
    @Dr.ManuelKuehner this "bug" is reported now. – Kpym Feb 26 '19 at 17:43
  • Thanks! I do not understand the technicalities but I appreciate the effort. – Dr. Manuel Kuehner Feb 26 '19 at 19:15
  • 1
    This has been fixed upstream: https://sourceforge.net/p/pgf/git/ci/65b8261c63c6f4adfca60106528e2d1bf1e2cb60/ – Henri Menke Feb 28 '19 at 08:01