Small issue for tikzmark and circuitikz

[Rmano]

(With reference to https://tex.stackexchange.com/questions/185279/anchoring-tikz-pics/611460?noredirect=1#comment1856966_611460 )

So --- I think I found the bug that made circuitikz unable to work with pics. The bug is mine on the circuitikz side, so nothing to do here. But I found a small issue for the pic anchor thing (I'll add a MWE when it will be possible to run it, unless you're ok with patching circuitikz for now).

The problem is that the compilation does not converge. I do a lot of calculations, and latexmk continued saying me that it needed to recompile. The "culprit" resulted to be:

--- auxone.aux	2025-05-23 12:16:05.241331093 +0200
+++ auxtwo.aux	2025-05-23 12:16:22.801595643 +0200
@@ -1,4 +1,4 @@
 \relax 
-\savepointas{two-origin}{pgfid1}{102.83437pt}{30.80986pt}
-\savepointas{two-anchor}{pgfid1}{62.59601pt}{22.7623pt}
+\savepointas{two-origin}{pgfid1}{102.83438pt}{30.80984pt}
+\savepointas{two-anchor}{pgfid1}{62.59601pt}{22.76227pt}
 \gdef \@abspage@last{1}

That is, rounding errors in the anchors' calculation. Given that I think that those numbers are well over maximum pgfmath precision, do you think it would be possible to round them a couple of decimal places less?)

[Rmano]

Related: circuitikz/circuitikz#866

[Rmano]

This is the code that creates the problem for me: (it needs circuitikz v1.8.0, released 5 minutes ago ;-) )

\documentclass{article}
\usepackage{circuitikz}
\usetikzlibrary{tikzmark}

\tikzset{ov/.pic = {
% reference anchor is -center
    \draw coordinate(-center)
    (-center) +(-1.2,-1) rectangle +(1.2,1)
    (-center) ++(-1.2,0.8) coordinate (-in 1)
    (-center) ++(-1.2,-0.8) coordinate (-in 2)
    (-center) ++(1.2,0.8) coordinate (-out 1)
    (-center) ++(1.2,-0.8) coordinate (-out 2)
    (-center) ++(0,1) coordinate (-up)
    (-in 1) -- ++(0.5,0) coordinate(-tmp)
    to[leD*, diodes/scale=0.6, led arrows from cathode, name=-led]
    (-tmp|- -in 2) -- (-in 2)
    (-out 1) -- ++(-0.5,0) coordinate(-tmp)
    to[pD*, diodes/scale=0.4, mirror, name=-pd1] ++(0,-0.5)
    edge[densely dashed] ++(0,-0.533) ++(0,-0.566)
    to[pD*, diodes/scale=0.4,mirror, name=-pd2] (-tmp|- -out 2) -- (-out 2)
% leave the position of the path at the center
    (-center);
    }
}
\begin{document}

Circuitikz: \pgfcircversion{} (\pgfcircversiondate)\par
Ti\emph{k}Z: \pgfversion{} (\pgfversiondate)\par\bigskip


\begin{tikzpicture}
    \draw (0,0) pic(one) {ov};
    \node [above] at (one-up) {O1};
    \draw[color=blue] (one-out 1) -- ++(1,0)
        % pic[pic anchor=(-in 1)](two) {ov};
        pic[rotate=45, transform shape, pic anchor=(-in 1)](two) {ov};
    \node [above] at (two-up) {O2};
\end{tikzpicture}
\end{document}

[loopspace]

tikzmark itself doesn't create those coordinates, it triggers them being recorded to the aux file but only in the same way that remember picture does. What tikzmark mainly does is to make those coordinates available to the document. So I have very little control over what gets written out.

Clearly, some micro-adjustments happen each time meaning that the picture shifts just enough to mean that those coordinates are different each time, and then latexmk notices the difference and so says that you need to recompile. Since it would be tricky to change how they are recorded, if instead they are rounded prior to use then the difference wouldn't lead to an actual change in the document and then they would stabilise.

So, for example, if the adjust scope position code did a bit of precision rounding then that would resolve the issue:

\tikzset{
  adjust scope position/.code={%
    \pgfutil@ifundefined{tikz@fig@name}%
    {\let\tikz@fig@name=\pgfutil@empty}{}%
    \tikz@resetexpandcount%
    \tikz@fig@mustbenamed
    \pgfkeysgetvalue{/tikz/scope anchor location}\tkzmk@anchor
    \ifx\tkzmk@anchor\tikz@auto@text
    \tikzset{local bounding box/.expanded=\tikz@fig@name}%
    \def\tkzmk@anchor{(\tikz@fig@name.\tikz@anchor)}%
    \fi
    \tikz@scan@one@point
    \pgfutil@firstofone(pic cs:\tikz@fig@name-origin)\relax
    \pgf@xa=\pgf@x
    \pgf@ya=\pgf@y
    \tikz@scan@one@point
    \pgfutil@firstofone(pic cs:\tikz@fig@name-anchor)\relax
    \advance\pgf@xa by -\pgf@x
    \advance\pgf@ya by -\pgf@y
    \tikzset{
      shift={({int(10*\the\pgf@xa)/10},{int(10*\the\pgf@ya)/10})}, % Round to nearest 0.1pt
      execute at end scope={%
        \tikzmark{\tikz@fig@name-origin}{(0,0)}%
        \tikzmark{\tikz@fig@name-anchor}{\tkzmk@anchor}%
      }
    }
  },
}

As an alternative, to avoid changing the internals of tikzmark, we could define a function that rounds the current shift part of the transformation matrix. This needs a little work to get it to be invoked at the right time and so the exact definition of the key needs a little thought, but in essence the following would do it:

\ExplSyntaxOn
\tl_new:N \l__tikzmark_matrix_tl
\tikzset{
  round~ shift~ to/.code={
    \pgfgettransform\l__tikzmark_matrix_tl
    \tl_show:N \l__tikzmark_matrix_tl
    \tl_set:Ne \l__tikzmark_matrix_tl
    {
      { \tl_item:Nn \l__tikzmark_matrix_tl {1} }
      { \tl_item:Nn \l__tikzmark_matrix_tl {2} }
      { \tl_item:Nn \l__tikzmark_matrix_tl {3} }
      { \tl_item:Nn \l__tikzmark_matrix_tl {4} }
      { \fp_eval:n { round( \tl_item:Nn \l__tikzmark_matrix_tl {5}, #1 ) } pt }
      { \fp_eval:n { round( \tl_item:Nn \l__tikzmark_matrix_tl {6}, #1 ) } pt }
    }
    \tl_show:N \l__tikzmark_matrix_tl
    \pgfsettransform\l__tikzmark_matrix_tl
  }
}
\ExplSyntaxOff

As written, this would be invoked as:

        pic[rotate=45, transform shape, pic anchor=(-in 1), next pic/.append style={round shift to=2}](two) {ov};

What might be more elegant is to build the next pic/.append style part into the user-level key.

Some of this could be included with tikzmark, since it does feel like an issue that might arise in more situations than this. I would be reluctant to impose a global precision but giving the ability for a user or package author to impose it for themselves feels reasonable.

Let me know your thoughts!

[Rmano]

I also think that forcing a rounding on any user is not a good idea, agreed. Moreover, I think 0.1pt is relatively too much. And the second solution (at least in that form) seems ok, but it has the problem that it will be LaTeX-only (well, I do not know if tikzmark is already LaTeX-only --- is it? I mean, can it be used in, say, ConTeXt?).

My preferred solution would be to add just a keyword, say sloppy, that applies to this pic, rounding to, for example, 0.01pt by default (that should suffice), but controlled by a global parameter. So it would be easier to use and to explain to the user:

pic[rotate=45, transform shape, pic anchor=(-in 1), sloppy]...

or even, to not pollute the namespace

pic[rotate=45, transform shape, pic rounded anchor=(-in 1)]...

(I am bad at names, as you can see.) That one is simple to explain: if you have any problem with repeated compilations not converging, use pic rounded anchor=... and try again. If it still does not work, you can set, for example, \tikzset{pic anchor rounding=2} or whatever...

[loopspace]

I'm happy with that. I marginally prefer the single pic rounded anchor key because it avoids having to consider all the variations of where the pic anchor and sloppy keys are placed and in what order. Controlling it via a global preference also makes sense. It could also be the case that there's a global option to make all pic anchors rounded.

Alternatively, the key pic anchor rounding could control the rounding and there's an option disable (or off) which removes the rounding. Then this could be set on a scope or picture and it would be in place for all pic anchors within. That way one wouldn't have to figure out which pic anchor was causing the trouble and change all the pic anchors to pic rounded anchors.

Hmm, I'm liking this idea. Can you think of any issues with it?

With regard to ConTeXt then I strongly suspect that tikzmark is not ConTeXt compatible. I use LaTeX3 code more and more these days and there's certainly some in tikzmark. It may not be in the basic tikzmark code, but I would have to tease it apart to make it ConTeXt compatible and no-one's yet asked me to do that!

[Rmano]

Alternatively, the key pic anchor rounding could control the rounding and there's an option disable (or off) which removes the rounding. Then this could be set on a scope or picture and it would be in place for all pic anchors within. That way one wouldn't have to figure out which pic anchor was causing the trouble and change all the pic anchors to pic rounded anchors.

I like it. It could be pic anchor rounding with a default to, say, 0.01pt (and maybe just 0.001pt could suffice, I don't know), and then having pic anchor rounding=1 to set it to 0.1pt. And yes, having pic anchor rounding=none or whatever to be able to switch it off locally. The default should be none, I think.

Then I think it should be useful to add some examples to the manual. I'll think I'll add tikzmark to the CircuiTikZ manual, to be able to explain it (it is quite difficult to concoct an example without the kind of messy calculations done by circuitikz...).

[loopspace]

Okay, so in 2a1a333 then I've introduced a key tikzmark round which can be used to impose rounding on coordinates defined with \tikzmark at the point of use. That is, when the pic cs coordinate system is invoked. This is used internally by the pic anchor so propagates through to that.

Use as:

tikzmark round=2, % 2 decimal places
tikzmark round=off, % disable
tikzmark round=none, % disable

Actually, I forgot a component of the disabling code so the above commit isn't the right one. It's the latest commit that is correct.

Anyway, here's your code with this key:

\documentclass{article}
\usepackage{circuitikzgit}
\usetikzlibrary{tikzmark,fpu}

\tikzset{ov/.pic = {
% reference anchor is -center
    \draw coordinate(-center)
    (-center) +(-1.2,-1) rectangle +(1.2,1)
    (-center) ++(-1.2,0.8) coordinate (-in 1)
    (-center) ++(-1.2,-0.8) coordinate (-in 2)
    (-center) ++(1.2,0.8) coordinate (-out 1)
    (-center) ++(1.2,-0.8) coordinate (-out 2)
    (-center) ++(0,1) coordinate (-up)
    (-in 1) -- ++(0.5,0) coordinate(-tmp)
    to[leD*, diodes/scale=0.6, led arrows from cathode, name=-led]
    (-tmp|- -in 2) -- (-in 2)
    (-out 1) -- ++(-0.5,0) coordinate(-tmp)
    to[pD*, diodes/scale=0.4, mirror, name=-pd1] ++(0,-0.5)
    edge[densely dashed] ++(0,-0.533) ++(0,-0.566)
    to[pD*, diodes/scale=0.4,mirror, name=-pd2] (-tmp|- -out 2) -- (-out 2)
% leave the position of the path at the center
    (-center);
    }
}
\begin{document}

Circuitikz: \pgfcircversion{} (\pgfcircversiondate)\par
Ti\emph{k}Z: \pgfversion{} (\pgfversiondate)\par\bigskip


\begin{tikzpicture}
    \draw (0,0) pic(one) {ov};
    \node [above] at (one-up) {O1};
    \draw[color=blue] (one-out 1) -- ++(1,0)
        % pic[pic anchor=(-in 1)](two) {ov};
        pic[tikzmark round=2, rotate=45, transform shape, pic anchor=(-in 1)](two) {ov};
    \node [above] at (two-up) {O2};
\end{tikzpicture}
\end{document}

The aux file for this seems to settle after two runs.

[Rmano]

OK, I think it's perfect. I'll add a notice about that in the manual. Now I think that the tikzmark manual just need a small example of using pic anchor; what about grabbing https://tex.stackexchange.com/a/745074/38080 ? It does (almost) depend on circuitikz.

[Rmano]

Hmm, if I use (in your code above) tikzmark round=3 I get:

! Dimension too large.
<recently read> \pgfmath@x 
                           
l.36 ...sform shape, pic anchor=(-in 1)](two) {ov}
                                                  ;
? 

and I know where it come from, but unfortunately pgfmath round only round to the integer, so there is no way to avoid the overflow unless you do something like

intpart = floor(x)
decpart = x - intpart
decround = round(decpart*10^n)/10^n
return intpart + decround 

which I am not 100% sure that will work for negative and positive numbers...

[loopspace]

I was trying to avoid LaTeX3 here, hence using pgfmath. I think your proposal will be fine, the only issue with negative numbers is that it might round .5 the wrong way, but this isn't somewhere that I expect that to matter.

[loopspace]

Apologies for the length of time it took, but 741ec1d implements better rounding code in that (as with your pseudocode) it only rounds the decimal part.

[Rmano]

Hi! How are you doing? Do you still need an example of tikzmark round? It would be nice to have a release before TeXLive 2026... 😉

Thanks!