diff options
Diffstat (limited to 'Master/texmf-dist/doc/latex/circuitikz/circuitikzmanual.tex')
| -rw-r--r-- | Master/texmf-dist/doc/latex/circuitikz/circuitikzmanual.tex | 31 |
1 files changed, 19 insertions, 12 deletions
diff --git a/Master/texmf-dist/doc/latex/circuitikz/circuitikzmanual.tex b/Master/texmf-dist/doc/latex/circuitikz/circuitikzmanual.tex index 37e8bffc107..04431723a11 100644 --- a/Master/texmf-dist/doc/latex/circuitikz/circuitikzmanual.tex +++ b/Master/texmf-dist/doc/latex/circuitikz/circuitikzmanual.tex @@ -178,7 +178,8 @@ A similar approach for \ConTeXt\ is available, with the file \texttt{t-circuitik This manual has been typeset with \Circuitikz{} \pgfcircversion{} (\pgfcircversiondate) on \TikZ{} \pgfversion{} (\pgfversiondate). -\subsection{Incompatible packages} +\subsection{Incompatible packages}\label{sec:incompatible-packages} + \TikZ's own \texttt{circuit} library, which was based on \Circuitikz, (re?)defines several styles used by this library. In order to have them work together you can use the \texttt{compatibility} package option, which basically prefixes the names of all \Circuitikz\ \texttt{to[]} styles with an asterisk. So, if loaded with said option, one must write \verb!(0,0) to[*R] (2,0)! and, for transistors on a path, \verb!(0,0) to[*Tnmos] (2,0)!, and so on (but \verb!(0,0) node[nmos] {}!). See example at page~\pageref{ex:compatibility}. @@ -245,6 +246,7 @@ The \texttt{use fpu reciprocal} key seems to have no side effects, but given tha Here, we will provide a list of incompabilitys between different version of \Circuitikz. We will try to hold this list short, but sometimes it is easier to break with old syntax than including a lot of switches and compatibility layers. In general, changes that would invalidate a circuit (changes of polarity of components and so on) are almost always protected by a flag; the same is not true for purely aesthetic changes. If unsure, you can check the version at your local installation using the macro \verb!\pgfcircversion{}!. \begin{itemize} + \item Since \texttt{v1.5.1}\footnote{Do not use \texttt{v1.5.0}, it's buggy.} color management (see section~\ref{sec:colors}) and the details of how the shapes are drawn and protected by the external drawing options has changed. There should be no substantial changes to the circuits, though. \item The \TikZ{} fix for \texttt{to[...] +(x,y)} behavior (see~\ref{sec:path-relative-coordinates}) uncovered a bug in the positioning of the labels in \Circuitikz{} that is present since \texttt{v0.8}. So you \textbf{must} upgrade to \texttt{v1.4.1} or better if you have \TikZ{} newer than \texttt{3.1.8} (and you want/need to use the \texttt{+(x,y)} syntax). \item There have been changes in (internal) parameters for capacitors in \texttt{v1.4.1}; now to change them you should use the style interface (see~\ref{sec:capacitors-styling}). \item \Circuitikz{} \texttt{v1.4.0} introduce the rollback system for the package when using LaTeX; that (at least in principle) should be completely backward-compatible. @@ -3308,10 +3310,10 @@ Choosing the proper left/right shape results in easily build ``mixed'' connector \begin{LTXexample}[varwidth=true, basicstyle=\small\ttfamily] \begin{circuitikz}[] \path (0,2); % for the bounding box, text is not accounted for - \draw (0,1) -- ++(1,0) node[iecsocketL](s1){S1}; - \draw [red] (s1.e) node[iecplugR](p1){P1} (p1.e) -- ++(1,0); + \draw (0,1)--++(1,0) node[iecsocketL](s1){S1}; + \draw [color=red](s1.e) node[iecplugR](p1){P1} (p1.e)--++(1,0); \draw (0,0) -- ++(1,0) node[iecplugL](p2){P2}; - \draw[blue] (p2.e) node[iecsocketR](s2){S2} (s2.e) -- ++(1,0); + \draw [color=blue](p2.e) node[iecsocketR](s2){S2} (s2.e)--++(1,0); \end{circuitikz} \end{LTXexample} @@ -8391,22 +8393,26 @@ To correct the line ending, there are support shapes to fill the missing rectang \end{tikzpicture} \end{LTXexample} -\section{Colors} - +\section{Colors}\label{sec:colors} -Color support in \Circuitikz{} has been quite limited since version 1.5.0; form that one onward there has been an effort to make component's behavior more intuitive. +Color support in \Circuitikz{} has been quite limited up to version 1.5.1; form that one onward there has been an effort to make component's behavior more intuitive. Part of the problem is how colors in paths are treated by \TikZ{} itself; you can see part of the discussion \href{https://github.com/circuitikz/circuitikz/issues/605}{this issue} and in \href{https://tex.stackexchange.com/questions/634987/pgf-basic-layer-struggling-again-with-colors}{this question on TeX.SX} --- many thanks to \texttt{@muzimuzhi} for helping there. Basically, nodes are drawn \emph{after} the path is completed, and color is applied to the path at the end. Look at this code (pure \TikZ, no \Circuitikz{} here): \begin{LTXexample}[varwidth=true] -\tikz \draw[thick] (0,0) -- (1,0) {[color=red] -- (2,0) node[draw]{}} --(3,0); - +\tikz \draw[thick] (0,0) -- (1,0) {[color=red] -- (2,0) node[draw]{}} --(3,0); \par \tikz \draw[thick] (0,0) -- (1,0) [color=red] -- (2,0) node[draw]{} --(3,0); \end{LTXexample} -So the path is drawn with the last ``effective'' (in current group) color. The deferred behavior of the color properties is very difficult to track for \Circuitikz, especially when the shorthand \texttt{color-name} (e.g., \texttt{red} instead of \texttt{color=red}) is used. \Circuitikz{} will try to patch the default commands to keep track of the ``current color''; if it fails will give a warning like \texttt{patch failed, use only explicit color=...}. +So the path is drawn with the last ``effective'' (in current group) color. The deferred behavior of the color properties is very difficult to track for \Circuitikz, especially when the shorthand \texttt{color-name} (e.g., \texttt{red} instead of \texttt{color=red}) is used. \Circuitikz{} will try to keep track of the colors specified by \texttt{color=...} and \texttt{fill=...}, but if you use the implicit way (\texttt{\textbackslash draw[red]...}) it often fails. -Before 1.5.0, \Circuitikz{} used black as the default color. Now it tries to follow the current color, as \TikZ does normally; but notice that there is a difference with the fill strategy: +If you're adventurous, you can try to add +\begin{lstlisting}[numbers=none] + \usepackage{regexpatch}\ctikzPatchImplicitColor +\end{lstlisting} +after loading \Circuitikz, and it will try to patch the default commands to keep track of the ``current color''; if it fails will give a warning like \texttt{patch failed, use only explicit color=...}. This is, unfortunately, not compatible with package \texttt{xpatch} (and much others, which load \texttt{xpatch}).\footnote{version \texttt{1.5.0} loaded it unconditionally for LaTeX; please do not use it}. + +Before 1.5.0, \Circuitikz{} used black as the default color. Now it tries to follow the current color, as \TikZ{} does normally; but notice that there is a difference with the fill strategy: \begin{LTXexample}[pos=t] \color{red} @@ -8547,7 +8553,7 @@ This fill color will override any color defined by the style (see section~\ref{s ;\end{circuitikz} \end{LTXexample} -You can combine shape colors with fill colors, too, but you should use the \texttt{draw} color option style for this: +You can combine shape colors with fill colors, too, but you should use the explicit \texttt{color} option style for this: \begin{LTXexample}[varwidth=true] \begin{circuitikz} \draw[color=red] @@ -8620,6 +8626,7 @@ Also, since \texttt{v1.2.3}, you can set the key \texttt{open poles fill} (defau \end{circuitikz} \end{LTXexample} + \section{FAQ: Frequently asked questions} \def\faqQ{\par\medskip\noindent\textbf{Q: }} |