Using |- and cycle together can cause bad corners

[hammondkd]

Brief outline of the bug

As initially reported on TeX Stack Exchange (https://tex.stackexchange.com/questions/754905), using a combination of scale, cycle, and right-angle corners can result in improperly closed corners.

Minimal working example (MWE)

\documentclass{standalone}
\usepackage{tikz}

\begin{document}
\begin{tikzpicture}[scale=0.9]
  \draw[draw=red, fill=red, fill opacity=0.3, thick]
    (0.25, 5.8) -| (0.45, 6.2) -| cycle;
\end{tikzpicture}
\end{document}

Note that adding anything else (e.g., a point that does not draw anything) after the \draw command causes the corner to look like it's supposed to look.

[muzimuzhi]

Seems caused by rounding errors.

-| cycle (also holds for |- cycle) is reduced to

-| (current subpath start) -- cycle

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

Line 2801 in 8e552b1

\def\tikz@cycle@expander@add#1ycle{#1(current subpath start)--cycle}%

But the calculated (current subpath start) node anchor under specific scale may slightly differ from the real "current subpath start" point (stored in \pgfsyssoftpath@lastmoveto). This causes an extremely short close path, and it seems many PDF viewers decide to not render such a short close path.

pgf/tex/generic/pgf/modules/pgfmoduleshapes.code.tex

Lines 1106 to 1112 in 8e552b1

	% Special current path start coordinate:
	\expandafter\def\csname pgf@sh@ns@current subpath start\endcsname{coordinate}%
	\expandafter\def\csname pgf@sh@np@current subpath start\endcsname{%
	\def\centerpoint{\expandafter\pgfqpoint\pgfsyssoftpath@lastmoveto}%
	}%
	\expandafter\def\csname pgf@sh@nt@current subpath start\endcsname{{1}{0}{0}{1}{0pt}{0pt}}%
	\expandafter\def\csname pgf@sh@pi@current subpath start\endcsname{\pgfpictureid}%

(Here specific scale means a non-identical coordinate transformation matrix $T$. When getting a node anchor, something like $\text{relative\_anchor\_point} * T / T$ is computed, and the rounding error occurs.)

Tested on macOS, Adobe Acrobat Reader is the only viewer which doesn't give bad corners, while all of the TeXstudio's embedded poppler-based viewer, Skim, and in-browser PDFjs reproduce the bad corners.

On tikz side, maybe we can change the reduction for -| cycle and |- cycle to add only one, rather than two line-to'es.

The following example shows that the rounding error thus the bad corner issue is sensitive to the scaling ratio. It only reproduces if $\text{scaling\_ratio} \ne 2^k, k \in \mathbb{Z}$.

\documentclass{article}
\usepackage{tikz}

\makeatletter
\def\showpgfpath#1{%
  \begingroup
  \def\pgfsyssoftpath@movetotoken##1##2{move-to (##1, ##2)^^J}%
  \def\pgfsyssoftpath@linetotoken##1##2{line-to (##1, ##2)^^J}%
  \def\pgfsyssoftpath@closepathtoken##1##2{close^^J}%
  \message{#1}%
  \endgroup
}
\makeatother

\begin{document}
% further simplified
\foreach \i in {0.5, 0.9, 1, 3, 4, 5} {
  \begin{tikzpicture}[scale=\i]
    \draw[ultra thick, save path=\mypath]
      (0, .2) -| (0.2, .4) -| cycle;
    \path[use path=\mypath];
    \message{^^J! debug: scale=\i}%
    \showpgfpath{\mypath}%
    \node[anchor=north] at (0.1, 0.2) {\i};
  \end{tikzpicture}
}
\end{document}

PDF rendered by TeXstudio's embedded PDF viewer, problem reproduces when scale=.9, 3, 5

PDF rendered by Adobe Acrobat Reader, all fine

log output

! debug: scale=0.5
move-to (0.0pt, 2.84523pt)
line-to (2.84523pt, 2.84523pt)
line-to (2.84523pt, 5.69046pt)
line-to (0.0pt, 5.69046pt)
line-to (0.0pt, 2.84523pt)
close

! debug: scale=0.9
move-to (0.0pt, 5.12137pt)
line-to (5.12137pt, 5.12137pt)
line-to (5.12137pt, 10.24275pt)
line-to (0.0pt, 10.24275pt)
line-to (0.0pt, 5.12134pt)
close

! debug: scale=1
move-to (0.0pt, 5.69046pt)
line-to (5.69046pt, 5.69046pt)
line-to (5.69046pt, 11.38092pt)
line-to (0.0pt, 11.38092pt)
line-to (0.0pt, 5.69046pt)
close

! debug: scale=3
move-to (0.0pt, 17.07138pt)
line-to (17.07138pt, 17.07138pt)
line-to (17.07138pt, 34.14276pt)
line-to (0.0pt, 34.14276pt)
line-to (0.0pt, 17.0711pt)
close

! debug: scale=4
move-to (0.0pt, 22.76184pt)
line-to (22.76184pt, 22.76184pt)
line-to (22.76184pt, 45.52368pt)
line-to (0.0pt, 45.52368pt)
line-to (0.0pt, 22.76184pt)
close

! debug: scale=5
move-to (0.0pt, 28.4523pt)
line-to (28.4523pt, 28.4523pt)
line-to (28.4523pt, 56.9046pt)
line-to (0.0pt, 56.9046pt)
line-to (0.0pt, 28.45184pt)
close

[muzimuzhi]

On tikz side, maybe we can change the reduction for -| cycle and |- cycle to add only one, rather than two line-to'es.

Or, change how the special predefined nodes such as current bounding box and current subpath start (https://tikz.dev/base-nodes#sec-106.4) are used as coordinates.

[hmenke]

Does this also happen with zero-length curveto paths?

Also this is the result for Evince 48.1 (based on Poppler 25.07.0)

EDIT: Hm, I can reproduce it with the MWE from the issue, but it depends on the zoom level of the viewer. 🤔

[ilayn]

Closing the path is a PS/PDF primitive. It should not be effected by any scaling. PDF viewer might also buggy.

[hmenke]

Ah, I misunderstood the problem. The problem is roundoff error in the construction of -| cycle.

Compiling these two versions of the input file

--- a/test.tex
+++ b/test.tex
 \pdfcompresslevel=0
 \pdfobjcompresslevel=0
 \documentclass{standalone}
 \usepackage{tikz}
 \begin{document}
 \begin{tikzpicture}[scale=0.9]
-  \draw[thick] (0.25, 5.8) -| (0.45, 6.2) -| cycle;
+  \draw[thick] (0.25, 5.8) -| (0.45, 6.2) -| (0.25, 5.8) -- cycle;
 \end{tikzpicture}
 \end{document}

should not result in different PDFs but it does

--- a/test.pdf
+++ b/test.pdf
@@ -10,7 +10,7 @@
 0 g 0 G
 0 g 0 G
 0 g 0 G
-1 0 0 1 -5.979 -147.568 cm
+1 0 0 1 -5.979 -147.569 cm
 q 
 0 G 
 0 g 
@@ -21,8 +21,8 @@
 6.37796 147.96939 m 
 11.48027 147.96939 l 
 11.48027 158.17404 l 
-6.37791 158.17404 l 
-6.37791 147.96881 l 
+6.37796 158.17404 l 
+6.37796 147.96939 l 
 h 
 S 
 Q 

In particular the last coordinate should be at the same location as the first coordinate (6.37796 147.96939 m).

[muzimuzhi]

Ah, I misunderstood the problem. The problem is roundoff error in the construction of -| cycle.

Yes. My #1428 (comment) was incomplete thus a bit misleading.

For <coord1> -- ... <coordn> -| cycle;,

• ideally it should write the same PDF graphic content stream as

  <coord1> -- ... <coordn> -| <coord1> -- cycle;

  When rendering PDF, the close path operator results in a zero-length segment (and more, but irrelevant to this issue). It seems all PDF viewers succeeded in this case.
• but depending on the coordinates and transformations, roundoff error occurs thus what tikz actually writes to PDF is

  <coord1> -- ... <coordn> -| ($<coord1>+<shift>$) -- cycle;

  So when rendering PDF, the close path operator results in a short segment, in this case extremely short. Some PDF viewers failed so the rendering result looked like that for

  <coord1> -- ... <coordn> -| ($<coord1>+<shift>$);

  a path not closed.