2

(Possibly related to this, but the example and the error are very different from what I've come up with. Plus it's a question from 2015, and the answers have been updated in 2017 and no later, so I expect things might have changed in the meanwhile.)

Here's a MWE

\documentclass{article}

\usepackage{tikz} \usetikzlibrary{ external, tikzmark }

\tikzexternalize[only named=true, prefix=externalized/]

\begin{document}

\tikzsetnextfilename{green} \tikz{\draw[fill=green] (0,0) circle (12pt);}\dots

A node: \tikzmarknode{NodeName}{TikZ mark node} % the following env is not actually necessary to trigger the error \begin{tikzpicture}[remember picture, overlay] \node[yshift=-0.9em] at (NodeName) {some text under it}; \end{tikzpicture}

\end{document}

which errors like this

...
===== Image 'externalized/green' is up-to-date. ======

! Package tikz Error: Giving up on this path. Did you forget a semicolon?.

See the tikz package documentation for explanation. Type H <return> for immediate help. ...

l.16 A node: \tikzmarknode{NodeName}{TikZ mark node}

[1{/usr/local/texlive/2023/texmf-var/fonts/map/pdftex/updmap/pdftex.map}<./exte rnalized/green.pdf>] (./externalizing.aux)) (see the transcript file for additional information) 413 words of node memory still in use: 3 hlist, 1 vlist, 1 rule, 2 glue, 3 kern, 1 glyph, 5 attribute, 48 glue_spec , 5 attribute_list, 2 write nodes avail lists: 2:179,3:87,4:10,5:24,6:4,7:196,9:78,11:2 </usr/share/fonts/OTF/lmroman10-regular.otf> Output written on externalizing.pdf (1 page, 5387 bytes). SyncTeX written on externalizing.synctex.gz. Transcript written on externalizing.log.

As the example should suggest, in my actual usecase, I use \tikzmarknode to have a way to position a tikz node with some text with respect to inline text. I'm not interested in externalizing this picture, even because it would not make sense, I think, as all it does is provide positioning.

However, I do have other "ordinary" TikZ picture around that I do want to externalize.

Therefore, the fact that commenting \tikzexternalize is enough to avoid the error is clearly not viable.

The obvious solution, which I'm adopting so far, is to enclose every usage of \tikzmarknode+tikzpicture within \tikzexternaldisable and \tikzexternalenable, like this:

\documentclass{article}

\usepackage{tikz} \usetikzlibrary{ external, tikzmark }

\tikzexternalize[only named=true, prefix=externalized/]

\begin{document}

\tikzsetnextfilename{green} \tikz{\draw[fill=green] (0,0) circle (12pt);}\dots

\tikzexternaldisable A node: \tikzmarknode{NodeName}{TikZ mark node} % the following env is not actually necessary to trigger the error \begin{tikzpicture}[remember picture, overlay] \node[yshift=-0.9em] at (NodeName) {some text under it}; \end{tikzpicture} \tikzexternalenable

\end{document}

However, I'm wondering why is that, and whether there's a better solution than disseminating \tikzexternaldisable and \tikzexternalenable around.

Furthermore, since I use only named=true, I don't understand why TikZ should attempt any externalization at all when meeting a \tikzmarknode.


From tlmgr gui I see that the table Local rev. (ver.) for tikzmark is 64819 (1.15).

Enlico
  • 2,592
  • Can you check what version of tikzmark you are using? The latest version (v1.15 from August 2022) explicitly disables externalisation for tikzmark and tikzmarknode. – Andrew Stacey May 07 '23 at 17:41
  • Also, I may be missing it but I don't see a description of the actual error in your post. Could you include a brief description of what happens and what should happen? – Andrew Stacey May 07 '23 at 17:44
  • @AndrewStacey, I've added the info you asked, and yes, I totally forgot to paste the example. Now I've included it. – Enlico May 08 '23 at 05:37
  • Given the response from TikZ/PGF about the status of the external library, would you mind if I edited your post a little bit so that this could become an "information" post about this issue? I'd change the title to refer to inline tikz rather than tikzmark and add a bit at the beginning about where this is really from, then leave your post as an example of its occurrence. That way, if someone else comes across this in different circumstances then we can point them to this post. – Andrew Stacey May 08 '23 at 11:22

1 Answers1

2

This is not actually a tikzmark issue, but rather is related to differing behaviour in TikZ with and without the external library. I can stop the error occurring with tikzmark but that doesn't fix the underlying issue.

In short, the following code is fine without the external library loaded but not with it:

\tikz {\draw (0,0) -- (1,0)}

With the external library then Tikz complains about the missing semi-colon at the end of the \draw command. The fact that this works (when the external library is not loaded) is by design - looking at the TikZ code then there is an explicit check for this via a conditional \iftikz@auto@end@path which finishes a path if this hasn't already been triggered by a semi-colon. And just before the definition of the \tikz command there is an example in the code that doesn't have the semi-colon:

% Example:
%
% The rectangle \tikz{\draw (0,0) rectangle (1em,1ex)} has width 1em and
% height 1ex.

The reason you are seeing this with \tikzmarknode is that when all the extra is stripped away then it becomes \tikz {\node[node contents={Stuff}]} without the semi-colon. Now, I can put the semi-colon in there - line 507 of tikzlibrarytikzmark.code.tex should be changed to ];}% - but that doesn't explain what is really going on.

I've raised an issue on the TikZ/pgf issue tracker and the TikZ/pgf team has responded saying that the external library is currently unmaintained but that there are alternatives that are more robust. So I've add the semi-colon in to the tikzmark library on github (and will send to CTAN next time I'm sending them stuff) as above to stop the error from arising as that at least means that tikzmark doesn't cause this error to arise.

(I'll also just note that as far as I can tell, this error doesn't actually do anything - the picture still gets processed - so equivalently you could just ignore it.)

Andrew Stacey
  • 153,724
  • 43
  • 389
  • 751
  • 1
    It would be nice if the pgf/tikz documentation included some indication of which bits are unmaintained and thought poorly designed. You shouldn't have to expend this much effort to ascertain their position. Ideally, they should be in a different section of the manual and marked deprecated or something. – cfr Oct 31 '23 at 19:34