# Problem description

As described in the "Terminal shapes" section (currently section 4.12) of the circuitikz manual, the "open circuit" versions of bipole nodes are

[...] by default filled with the color specified by the key open nodes fill (by default white), but you can override locally it [sic] with the fill parameter.

This default is not always desirable, specifically in situations where the background color itself is not white, such as illustrated in the MWE below.

# Desired solution

I would like to not fill open circuit terminals at all (but instead only draw their contour). My hope is to use the fill=none option to redefine the key open nodes fill accordingly for the entire document, but I am - undoubtedly due to my only vague understanding of TikZ styles and PGF keys - not sure how to achieve this.

# Minimal working example

Save to test.tex and compile via pdflatex test, then see TODO comments for things I already tried unsuccessfully.

\documentclass[tikz]{standalone}%

% Background color
\usepackage{pagecolor}%
\usetikzlibrary{decorations, decorations.text,backgrounds}%

\usepackage{circuitikz}%
\standaloneenv{circuitikz}% Correct image cropping with circuitikz & standalone

%%%% TODO: Some things I tried that do NOT work:
%\tikzset{open nodes fill/.style={none}}
%\tikzset{open nodes/.style={fill=none}}
%\tikzstyle{open nodes fill}=[none]

\begin{document}%

\begin{circuitikz}[background rectangle/.style={fill=gray}, show background rectangle]%
%%%%% TODO: Some alternatives that I tried that do NOT work:
%\begin{circuitikz}[background rectangle/.style={fill=gray}, show background rectangle, open nodes/.style={fill=none}]%
%\begin{circuitikz}[background rectangle/.style={fill=gray}, show background rectangle, open nodes fill/.style={none}]%
%\begin{circuitikz}[background rectangle/.style={fill=gray}, show background rectangle, open nodes fill/.style={fill=none}]%

% Test: Resistor with two open circuit ends that I'd like to not be filled
\draw (0,0) to[short, o-o, R] (3,0);%

%%%%% TODO: Not even a local change seems to work:
%\draw (0,0) to[short, o-o, R, fill=none] (3,0);%

\end{circuitikz}%

\end{document}%


First of all: you found a bug, in the sense that the parameter open poles opacity (described in section 6.1.1 of the manual) was not working as expected when a fill color was defined (duh! Thanks).

The fix will soon be released, but for now, you can use the "git" version as explained here: https://circuitikz.github.io/circuitikz/.

### Now the answer, once the bug is fixed

Basically, you probably don't want it. But let's see what happens. To explain it, I reduced a bit your MWE to this:

\documentclass[tikz]{standalone}%
\usepackage{pagecolor}%
\usetikzlibrary{decorations, decorations.text,backgrounds}%
\usepackage{circuitikz}%
\begin{document}%

\colorlet{mybgcolor}{cyan!20}
\begin{tikzpicture}[background rectangle/.style={fill=mybgcolor},
show background rectangle]%
\draw (0,0) to[R, o-*,] (3,0);%
\end{tikzpicture}%

\end{document}%


which results in:

Notice that you should not write to[short, R]: one component can be a resistor or a short circuit, not both. Sometimes it works, but it can explode in interesting ways...

To have transparent poles, you can use the key poles/open fill opacity. But the result is not what you probably want:

\ctikzset{poles/open fill opacity=0.0}
\draw (0,0) to[R, o-*,] (3,0);


What happened? In TikZ paths, nodes are drawn after the path; you can see that it is exactly the same for normal TikZ shapes:

\ctikzset{poles/open fill opacity=0.0}
\draw (0,1) node[circle,draw,fill=white,fill opacity=0]{}
-- (3,1)  node[circle,draw,fill]{};
\draw (0,0) to[R, o-*,] (3,0);


...and this is the reason why poles override opacity, normally, so that they are always filled.

### Solution 1: Placing the nodes first

You can have a satisfactory solution (since v1.2.1, that is) by placing the nodes, and after that using the node name to connect a component:

\ctikzset{poles/open fill opacity=0.0}
\node [ocirc](A) at (0,0){}; \node[circ](B) at (3,0){};
\draw (A) to[R, o-*,] (B);


This works because now that the nodes are there before the path is set, TikZ uses the "border anchors" of the nodes to connect. Or you can place the poles after the component, using the explicit anchors (A.west), (A.east), etc.

### Solution 2: Match fill color to background color

All of this becomes much more complex if there are crossing wires on the poles, so the best solution for normal usage is to let the open poles be filled, and just use a \colorlet as in the example for the background color and fill with that:

\ctikzset{open poles fill=mybgcolor}
\draw (0,0) to[R, o-*] (3,0);


(Please notice that for this last option, you do not need to use the fixed version of circuitikz, the bug was related only to the opacity!)

• Thanks, this is excellent! Yes, the to[short, R] was actually unintended (I added the resistor only on second thought to better illustrate this being a question related to CircuiTikZ, specifically, and forgot to remove the [short] option. Thanks for the credits on the GitHub issue! The suggested solution of placing the nodes first probably works best for me (since I need to accommodate cases in which the background color needs to remain flexible; that's why the last proposed solution does not work in my case). Jun 25 at 4:44
• A quick follow-up question regarding "Workaround 1" (as I have taken the liberty to now name it above), ie, setting the open nodes fill opacity to 0, placing the nodes first, and then connecting to their .east/.west: I tried to implement this on my system (yes, CircuiTikZ is v1.3.0), but I still get non-transparent open nodes. I presume this is due to the bug you described above that is now fixed - is that correct? Jun 25 at 14:51
• @FlorianH. Yes, that's the bug I cited. You can use/check the new version by downloading circuitikz.github.io/circuitikz/circuitikzgit.sty , saving it in the same directory as your main LaTeX file, and changing \usepackage{circuitikz} into \usepackage{circuitikzgit}. (A recent version is 1.3.8, I'll release 1.4.0 soon) Jun 25 at 15:13
• Release 1.3.9 is on its way to CTAN with the fix. Jun 27 at 9:44