## What happened

The error

! Package pgf Error: No shape named intersection-1' is known.


is produced when compiling the following with pdfLaTeX:

\documentclass{standalone}
\usepackage{tikz}
\usetikzlibrary{intersections,calc}

\begin{document}
\begin{tikzpicture}
\draw[name path=line,smooth] (0,4.5)--(1.5,4.5);
\draw[name path=curve,smooth] (1.5,6) to[out=270,in=90] (0,3);
\draw[name intersections={of=line and curve}] (intersection-1) circle[radius=0.1]; % Error here
\end{tikzpicture}
\end{document}


When commenting out the intersection-searching line in the code above, the following diagram is produced:

Clearly, there exists exactly one intersection between the curve and the line.

## General purpose of code

Given an arbitrary y coordinate, e.g., y=4.5, I want to find the corresponding x coordinate on a given curve after the curve was drawn (I learn what the y coordinate is only after the curve is processed.) Therefore, I create the horizontal line (0,4.5)--(1.5,4.5), intentionally extending it in the x direction to ensure that it intersects with the curve, and then proceed to finding the intersection between the two. After the intersection is found, I \path to it and then call \pgfgetlastxy to find the x coordinate as pt (not shown on the MWE.)

The intention is to include the code in an already-existing LaTeX-written book composed by my Master's research supervisor, which is moving towards completion. As such, changing the typesetting system to anything other than pdfLaTeX is, for practical reasons, impossible at this stage.

## Research so far

1. Zarko in their answer to TikZ intersection not found suggests discarding units (pt, cm, etc.) in the code, but my example doesn't use any units.
2. Qrrbrbirlbel in their answer to TikZ doesn't find all intersections between plot and a line advises to use the smooth option, but the example above uses it in the drawing of both the curve and the line, without success.
3. Gonzalo Medina in their answer to TikZ not computing intersection urges to remove spaces between coordinates and the -- connectors, which my MWE is using, again without results.
4. Zarko notices in Intersection between several lines and a curve using Tikz that the reason for the error is that some curves simply don't intersect, but the curve and line in the MWE above clearly do.
5. To demonstrate that the intersections Tikz library succeeds in finding intersections for similar cases, I run the code
\documentclass{standalone}
\usepackage{tikz}
\usetikzlibrary{intersections,calc}

\begin{document}
\begin{tikzpicture}
\draw[name path=line,smooth] (0,5)--(1.5,5);
\draw[name path=curve,smooth] (1.5,6) to[out=270,in=90] (0,3);
\draw[name intersections={of=line and curve}] (intersection-1) circle[radius=0.1];
\end{tikzpicture}
\end{document}


which successfully generates

[Thanks to hpekristiansen for the recommendation to use circle instead of the uncentered and hard-to-see $\circ$ and to gernot for the recommendation to shorten the curve to the segment y in [3,6], which is where the issue occurs.]

## Software Specifications

Executing pdflatex --version in my Windows 10's CMD outputs

MiKTeX-pdfTeX 4.0.1 (MiKTeX 20.7)
TeX is a trademark of the American Mathematical Society.
using bzip2 version 1.0.6, 6-Sept-2010
compiled with curl version 7.61.1; using libcurl/7.61.1 WinSSL
compiled with expat version 2.2.6; using expat_2.2.6
compiled with jpeg version 9.3
compiled with liblzma version 50020042; using 50020042
compiled with libpng version 1.6.37; using 1.6.37
compiled with libressl version LibreSSL 2.8.2; using LibreSSL 2.8.2
compiled with MiKTeX Application Framework version 4.0; using 4.0
compiled with MiKTeX Core version 4.0; using 4.0
compiled with MiKTeX Archive Extractor version 4.0; using 4.0
compiled with MiKTeX Package Manager version 4.0; using 4.0
compiled with poppler version 0.60.1
compiled with uriparser version 0.9.2
compiled with zlib version 1.2.11; using 1.2.11


When placing \listfiles at the top of the document, the following information is output to the console:

 *File List*
standalone.cls    2018/03/26 v1.3a Class to compile TeX sub-files standalone
shellesc.sty    2019/11/08 v1.0c unified shell escape interface for LaTeX
ifluatex.sty    2019/10/25 v1.5 ifluatex legacy package. Use iftex instead.
iftex.sty    2020/03/06 v1.0d TeX engine tests
xkeyval.sty    2014/12/03 v2.7a package option processing (HA)
xkeyval.tex    2014/12/03 v2.7a key=value parser (HA)
standalone.cfg    2018/03/26 v1.3a Default configuration file for 'standalone'
class
article.cls    2019/12/20 v1.4l Standard LaTeX document class
size10.clo    2019/12/20 v1.4l Standard LaTeX file (size option)
tikz.sty    2020/01/08 v3.1.5b (3.1.5b)
pgf.sty    2020/01/08 v3.1.5b (3.1.5b)
pgfrcs.sty    2020/01/08 v3.1.5b (3.1.5b)
everyshi.sty    2001/05/15 v3.00 EveryShipout Package (MS)
pgfrcs.code.tex
pgfcore.sty    2020/01/08 v3.1.5b (3.1.5b)
graphicx.sty    2019/11/30 v1.2a Enhanced LaTeX Graphics (DPC,SPQR)
graphics.sty    2019/11/30 v1.4a Standard LaTeX Graphics (DPC,SPQR)
trig.sty    2016/01/03 v1.10 sin cos tan (DPC)
graphics.cfg    2016/06/04 v1.11 sample graphics configuration
pdftex.def    2018/01/08 v1.0l Graphics/color driver for pdftex
pgfsys.sty    2020/01/08 v3.1.5b (3.1.5b)
pgfsys.code.tex
pgfsyssoftpath.code.tex    2020/01/08 v3.1.5b (3.1.5b)
pgfsysprotocol.code.tex    2020/01/08 v3.1.5b (3.1.5b)
xcolor.sty    2016/05/11 v2.12 LaTeX color extensions (UK)
color.cfg    2016/01/02 v1.6 sample color configuration
pgfcore.code.tex
pgfcomp-version-0-65.sty    2020/01/08 v3.1.5b (3.1.5b)
pgfcomp-version-1-18.sty    2020/01/08 v3.1.5b (3.1.5b)
pgffor.sty    2020/01/08 v3.1.5b (3.1.5b)
pgfkeys.sty
pgfkeys.code.tex
pgfmath.sty
pgfmath.code.tex
pgffor.code.tex
tikz.code.tex
l3backend-pdfmode.def    2020-08-07 L3 backend support: PDF mode
supp-pdf.mkii
epstopdf-base.sty    2020-01-24 v2.11 Base part for package epstopdf
***********


How should the code in the 1st MWE be corrected to eliminate the error, without loading additional libraries into the document?

I am aware that there might exist other methods in TikZ to find the x coordinate on the curve based on the y coordinate (and will be thankful also to answers that mention such methods,) but I am primarily interested in learning why TikZ doesn't detect the intersection in the specific MWE above.

## UPDATE 11/12/2021

• Removing the smooth options doesn't remove the error. Thanks to gernot for suggesting this possible change.
• Compiling with LuaLaTeX doesn't solve the problem either, as the same error ! Package pgf Error: No shape named intersection-1' is known. persists. Thanks to user202729 for suggesting this possible change.
• Even slight changes in the coordinates or the direction degrees eliminate the problem, as Ignasi and gernot noticed, but I seek to find a solution that preserves the numbers in the question.
• gernot opened an issue on pgf's GitHub page as the 1st practical step to address the issue. You may follow the unfolding of the issue at https://github.com/pgf-tikz/pgf/issues/1076. Great thanks to gernot for their contribution!

## UPDATE 11/13/2021

I would like to thank ABC for the noticeably simple solution to the problem (see below!)

• Welcome to TeX.SX! Remove the smooth options, twice. Then it works, and the image looks fine. Nov 12, 2021 at 9:47
• I think there is a problem with inner computations, it works for 4.49 a 4.51 but not for 4.5. Nov 12, 2021 at 10:05
• Unrelated: Replace node {$\circ$}; with circle[radius=0.06]; to get a circle that is centred on the coordinate. Nov 12, 2021 at 10:22
• @MiriamBriskman I filed an issue, see github.com/pgf-tikz/pgf/issues/1076 (with a back reference) Nov 12, 2021 at 10:31
• If you change the ordering, it works: \draw[name intersections={of=curve and line}] (intersection-1) circle[radius=0.1];. The problem might thus be related to tex.stackexchange.com/q/418644.
– user255043
Nov 12, 2021 at 13:31

Disclaimer: this is not a complete answer in that it does not solve the underlying issue but just allows one to evade its consequences, i.e. it is something you could call workaround.

When tikz computes intersections between two paths, it sorts them by one of the two paths, and the default is to sort by the first path. However, under this thread it has been found that this does not always work as expected if the sorting path is a line. Indeed, if we either change the order of the paths:

name intersections={of=line and curve} -> name intersections={of=curve and line}


or tell tikz to sort by the second path:

name intersections={of=line and curve,sort by=curve}


the problem goes away. Note, however, that the bend left=0 trick does not seem to work in this case (unless I am missing something). (I kept the smooth keys in the code even though they do not have an effect because the paths do not include plots, just to reiterate that the problem has nothing to do with the smooth keys.)

\documentclass{standalone}
\usepackage{tikz}
\usetikzlibrary{intersections,calc}

\begin{document}
\begin{tikzpicture}
\draw[name path=line,smooth] (0,4.5) -- (1.5,4.5);
\draw[name path=curve,smooth] (1.5,6) to[out=270,in=90] (0,3);
\draw[name intersections={of=curve and line}] (intersection-1) circle[radius=0.1]; % Error here
\end{tikzpicture}

\begin{tikzpicture}
\draw[name path=line,smooth] (0,4.5) -- (1.5,4.5);
\draw[name path=curve,smooth] (1.5,6) to[out=270,in=90] (0,3);
\draw[name intersections={of=line and curve,sort by=curve}] (intersection-1) circle[radius=0.1]; % Error here
\end{tikzpicture}

\end{document}


• Thank you very much again for the perfectly-working workaround/solution! Hopefully, the contributors to TikZ will eliminate the issue in the next patch. Nov 12, 2021 at 14:48
• @MiriamBriskman You're welcome and I agree. In my opinion it is already amazing how well intersections work given that the computations are done by TeX, but I agree that without this issue it would be even better.
– user255043
Nov 12, 2021 at 14:54