-
Notifications
You must be signed in to change notification settings - Fork 110
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
name prefix and name suffix vs. edge: starting point of edge paths are incorrect #846
Comments
I may get the point of this issue. See tikz.code.tex. After line 5427, I add lines: \def\tikz@parse@node@temp{#2}%
\ifx\tikz@parse@node@temp\tikztostart%
\tikz@shapebordertrue%
\fi% this will set the I guess, the key point about this issue is , command \let\tikz@moveto@waiting=\relax |
Hm, I'm not sure whether this is the right way to approach this. It seems like a very symptomatic treatment. This patch also solves the problem and is maybe a bit more idiomatic. I'm not sure which way to go. --- a/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
+++ b/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
@@ -5431,7 +5431,13 @@
\tikz@shapebordertrue%
\def\tikz@shapeborder@name{\tikz@pp@name{#2}}%
\fi%
- \fi
+ \else\ifcsname pgf@sh@ns@#2\endcsname
+ \expandafter\ifx\csname pgf@sh@ns@#2\endcsname\tikz@coordinate@text%
+ \else
+ \tikz@shapebordertrue%
+ \def\tikz@shapeborder@name{#2}%
+ \fi%
+ \fi\fi
\fi%
\edef\tikz@marshal{\noexpand#1{\noexpand\pgfqpoint{\the\pgf@x}{\the\pgf@y}}}%
\tikz@marshal% |
Yes, I have learned it, your patch is very reasonable. |
We had similar things already. Usually, when a prefixed name does not exist TikZ either bails or just does nothing. Here we have the latter kind. If the prefixed node has no anchor, TikZ just does nothing and leaves \tikz@shapeborder@name unset. This has adverse effects when drawing edges, because they store the node name and restore it later. When the node name is restored, another name prefix is added to the already prefixed node that was stored. To remedy this, we now try the unprefixed node, when the prefixed node does not exist. This is probably not 100% compatible but whoever was relying on this behavior was on thin ice anyway. The new behavior is more of the kind of “do what I mean”.
It seems that there is some problem using nodes with
name prefix
(orname suffix
for that matter) and theedge
path construction. When one switches on either of them, the edge will connect to the node center of the starting node.Left is a scope with a
name prefix
, and the edge extends to the center of theA
node, where as in the right scope, where there is no node prefix, the result is as expected. If we use aname suffix
, the same problem arises.The text was updated successfully, but these errors were encountered: