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

bug at paths with a node as starting point #76

Closed
sistlind opened this issue May 19, 2017 · 5 comments · Fixed by #418
Closed

bug at paths with a node as starting point #76

sistlind opened this issue May 19, 2017 · 5 comments · Fixed by #418

Comments

@sistlind
Copy link
Collaborator

There is a bug, if a node is used as a starting point of a path without defining an explicit anchor:

\begin{circuitikz}
	\draw 
	
	%npns rechte Diffstufe
	(3,0) node[npn, anchor=C] (npn5) {}
	(npn5.B)++(1,0) node[] {$T_5$}% Beschriftung
	(4,0) node[npn, xscale=-1, anchor=C] (npn6) {}
	(npn6.B)++(-1,0) node[] {$T_6$}% Beschriftung
	(npn5.E)++(0.5,-0.5) node[npn,xscale=-1,anchor=C](npn4) {} 
	(npn4.B)++(-1,0) node[] {$T_4$}% Beschriftung
	
	%npns linke Diffstufe 
	(0,0) node[npn, anchor=C] (npn1) {}
	(npn1.B)++(1,0) node[] {$T_1$}% Beschriftung
	(1,0) node[npn, xscale=-1, anchor=C] (npn2) {}
	(npn2.B)++(-1,0) node[] {$T_2$}% Beschriftung
	(npn1.E)++(0.5,-0.5) node[npn, anchor=C](npn3) {}
	(npn3.B)++(1,0) node[] {$T_3$} % Beschriftung
	
	(npn1.C)++(0,1) node[](P3){}
	(npn6.C)++(0,1) node[](P4){}
	
	(npn1.C) to[short] (P3)
	(npn6.C) to[short] (P4)
	% weiter linke Diffstufe
	(npn1.E) -- (npn2.E) 
	(P3) to[R,l^=$R_1$,-] ++(0,2) node[vcc](){}
	(npn1.B) to[short,l_=LO-,-o] ++(-0.5,0) 
	(npn6.B) to[short,l=LO-,-o] ++(0.5,0) 
	(P4) to[R,l_=$R_2$,-] ++(0,2) node[vcc]{}
	(npn1.E)++(0.5,0) to[short,*-] (npn3.C)
	(npn3.B) to[short,l_=RF+,-o] ++(-0.5,0)
	(npn4.B) to[short,l=RF-,-o] ++(0.5,0)
	(npn5.B) -- (npn2.B)

	% weiter rechte Diffstufe
	(npn5.E) -- (npn6.E) 
	(npn5.E)++(0.5,0) to[short,*-] (npn4.C)
	
	%Verbindung zw. rechter und linker Diffstufe
	(npn3.E) -- (npn4.E)
	
	
	(npn5.C) to[short,-*] (P3)
	(npn2.C) to[short,-*] (P4)
	
	(npn2.B)++(0.2,0)to[short,-o]++(0,-0.5) node[](P5){}
	(P5)++(0,-0.3)  node[](P6){LO+}
	
	(npn3.E) ++(1.5,0) to[dcisource=$I1$,*-] ++(0,-2) node[ground](){}
	%------------------------------------------
	;
\end{circuitikz}

There appear anwanted lines(between emitter of T2 and R1 as well as from LO- to R2):
bugreport_circuitikz

Rmano added a commit to Rmano/circuitikz that referenced this issue Jul 1, 2020
This basically remove the patches introduced for issue circuitikz#58 and circuitikz#76

Reverts these:
   circuitikz@6efc2ee
   circuitikz@352d2bf

Then, it carefully builds the anchors without moving the start of the
path, and then join it with a leading --.
This was referenced Jul 1, 2020
@Rmano
Copy link
Collaborator

Rmano commented Jul 1, 2020

The new path fixes this. Notice that now the original example compiles like this:

image

Which is correct --- P3 and P4 are nodes and so they have a non-zero sizes. You can see what's happening if you add [draw=red] to them:

image

The behavior of forcing the start point at the center of the node is not standard and creates a lot of problems.

@Rmano Rmano reopened this Jul 1, 2020
Rmano added a commit to Rmano/circuitikz that referenced this issue Jul 1, 2020
This basically remove the patches introduced for issue circuitikz#58 and circuitikz#76

Reverts these:
   circuitikz@6efc2ee
   circuitikz@352d2bf

Then, it carefully builds the anchors without moving the start of the
path, and then join it with a leading --.
@Rmano Rmano closed this as completed in #418 Jul 1, 2020
@sistlind
Copy link
Collaborator Author

sistlind commented Jul 2, 2020

Hi @Rmano ,
if your last screenshot is the result of the new paths, in my opinion this is a huge drawback of this code, as it will break nearly all the drawings I have done for my lectures. I think it is not convenient to always specify the center anchor. Furthermore, nodes do not need to have a border. See difference between "coordinate" and "node".

EDIT: Did a closer look to this example. In this case it is ok, because P3 should really be declared as coordinate, not as path. Nevertheless, I am not sure if it does not break some other stuff.

Here I posted some other example: https://tex.stackexchange.com/questions/360264/correct-linejoins-at-tikz-to-path

@Rmano Rmano reopened this Jul 2, 2020
@Rmano
Copy link
Collaborator

Rmano commented Jul 2, 2020

Hi, I understand what you say, but the correct behavior in tikz is to connect the border of the nodes (even if invisible):

\documentclass[border=10pt]{standalone}
\usepackage{tikz}
\usetikzlibrary{arrows.meta,positioning,calc}
\begin{document}
\begin{tikzpicture}
    \node [](A) at (0,.2) {};
    \node [](B) at (2,.2) {};
    \node [](C) at (0,0) {};
    \node [](D) at (2,0) {};
    \draw (A) -- (B);
    \draw (C.center) -- (D.center);
\end{tikzpicture}
\end{document}

image

For this coordinates exists --- there are tens of post in TeX.SE about this, for example this,

Forcing the behavior of substitute the start and end node with the center to the center of nodes has as the effect of

  1. that you can't use to[R] (for example) between the border of two nodes, and that you have to manually select the appropriate anchor border;
  2. that you can't start the path replacement code with -- (\tikztostart), which will force the ugly hack for the line joins (that sometimes fails as in the case at Bad line junctions sometimes #417)

So I think it's a good thing to do (I created an embedded rollback point at 1.1.2 for backward compatibility on purpose); the original code is now correctly rendered by TikZ standard (and it's easily fixable by changing node to coordinate or adding inner sep=0pt to the two nodes).

To explain point 1 here: this code

\begin{tikzpicture}[every node/.style={inner sep=1cm}]
    \node [draw](A) at (0,0) {A};
    \node [draw](B) at (4,2) {B};
    \draw (A) to[R] (B);
\end{tikzpicture}

renders as

image

in 1.1.2 and previous
and as

image

now --- you can easily have the old behavior (if you really wanted it) with using A.center and B.center explicitly, but it's really complex to obtain the new one --- which in the rest of tikz is considered the correct one.

@Rmano
Copy link
Collaborator

Rmano commented Jul 2, 2020

Here I posted some other example: https://tex.stackexchange.com/questions/360264/correct-linejoins-at-tikz-to-path

Thanks, I will study this.

@Rmano
Copy link
Collaborator

Rmano commented Jul 2, 2020

Notice that in the example posted above now it works as should (in my opinion):

\begin{tikzpicture}[very thick]
    \draw (2,2) node[draw=red](A){};
    \draw (2,2) coordinate(B);
    \draw (0,0) to[esource](0,2) to[esource](A) to[esource] ++(2,-2);
    \begin{scope}[xshift=4.5cm]
        \draw (2,2) coordinate(B);
        \draw (0,0) to[esource](0,2) to[esource] (B) to[esource] ++(2,-2);
    \end{scope}
\end{tikzpicture}

image

The line joins are correct and the landing/starting positions from the node are the expected ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants