Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drawing paths that start at a node using \foreach #356

Open
pgf-tikz-bot opened this issue May 14, 2015 · 5 comments · May be fixed by #1316
Open

Drawing paths that start at a node using \foreach #356

pgf-tikz-bot opened this issue May 14, 2015 · 5 comments · May be fixed by #1316
Labels
Milestone

Comments

@pgf-tikz-bot
Copy link

Migrated from SourceForge
Author: nzeh
Timestamp: 2015-05-14 14:29:46.942000

In the following code example, two curves from (a) to (v2) and from (a) to (v3) are created, but a single curve from (a) to (v3) through (v2) should be drawn.

:::LaTeX
\begin{tikzpicture}
  \coordinate (v1)  at (0,0);
  \coordinate (c21) at (1,0);
  \coordinate (c22) at (2,0);
  \coordinate (v2)  at (2,1);
  \coordinate (c31) at (2,2);
  \coordinate (c32) at (3,2);
  \coordinate (v3)  at (4,2);
  \node[draw,inner sep=0pt,minimum size=6pt,circle] (a) at (v1) {};
  \draw (a) \foreach \i in {2,3} {.. controls (c\i1) and (c\i2) .. (v\i)};
\end{tikzpicture}

The correct path is drawn if the \foreach loop is manually expanded to

:::LaTeX
\draw (a) .. controls (c21) and (c22) .. (v2) .. controls (c31) and (c32) .. (v3);

The path is also drawn correctly using

:::LaTeX
\draw (v1) \foreach \i in {2,3} {.. controls (c\i1) and (c\i2) .. (v\i)};

but it is of course not shortened to start only at the node's boundary. This suggests that \foreach gets confused when the starting point of a path is a node rather than a coordinate.

@pgf-tikz-bot
Copy link
Author

Migrated from SourceForge
Author: talopnahli
Timestamp: 2015-05-23 21:49:17.140000

Hi Norbert,

This is not a bug. \foreach is designed this way such that at every spin of loop the last known coordinate is restored because \foreach runs in TeX group and at the end of the group the previous state is restored.

Hence, the expanded version of your loop is not what you wrote but

\draw (a) .. controls (c21) and (c22) .. (v2) 
      (a) .. controls (c31) and (c32) .. (v3);

In other words it doesn't concatenate the path syntax. It concatenates the paths.

@pgf-tikz-bot
Copy link
Author

Migrated from SourceForge
Author: nzeh
Timestamp: 2015-05-24 02:27:36.477000

Well, this would make some sense if the behaviour were consistent between
starting the path at a node or coordinate. Alas, it is not. When the
first element of the path is a node, the behaviour is as you describe.
When the first element is a coordinate, it does what I expected: each path
segment starts at the last vertex of the previous path segment.

Cheers,
Norbert

@pgf-tikz-bot
Copy link
Author

Migrated from SourceForge
Author: mo-gul
Timestamp: 2018-12-23 18:15:03.645000

  • labels: --> foreach
  • Description has changed:

Diff:


--- old
+++ new
@@ -1,4 +1,4 @@
-In the following code example, two curves from (a) to (v2) and from (a) to (v3) are created, but a single curve from (a) to (v3) through (v2) should be drawn.
+In the following code example, two curves from `(a)` to `(v2)` and from `(a)` to `(v3)` are created, but a single curve from `(a)` to `(v3)` through `(v2)` should be drawn.
 
     :::LaTeX
     \begin{tikzpicture}
@@ -13,7 +13,7 @@
       \draw (a) \foreach \i in {2,3} {.. controls (c\i1) and (c\i2) .. (v\i)};
     \end{tikzpicture}
 
-The correct path is drawn if the \foreach loop is manually expanded to
+The correct path is drawn if the `\foreach` loop is manually expanded to
 
     :::LaTeX
     \draw (a) .. controls (c21) and (c22) .. (v2) .. controls (c31) and (c32) .. (v3);

@hmenke
Copy link
Member

hmenke commented Nov 28, 2019

Aha! Another \iftikz@shapeborder issue.
Related #420

@hmenke hmenke added this to the 3.1.6 milestone Dec 17, 2019
@hmenke hmenke modified the milestones: 3.1.6, 3.1.7 Sep 3, 2020
@muzimuzhi
Copy link
Member

It seems backing-up \tikz@moveto@waiting only is enough, see https://tex.stackexchange.com/a/649375.

loopspace added a commit to loopspace/pgf that referenced this issue Apr 12, 2024
This commit adds more information to what TikZ remembers between foreach
iterations, and does so in a way that makes it easier to add other
macros and dimensions to the list of things it remembers, both at the
code level and via keys.

Fixes pgf-tikz#356, pgf-tikz#1047, pgf-tikz#1303, pgf-tikz#1313

Signed-off-by: Andrew Stacey <loopspace@mathforge.org>
@loopspace loopspace linked a pull request Apr 12, 2024 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

3 participants