# Clash between tikzmark, babel package (french) and babel tikzlibrary

Related : Tikzmark and french seem to conflict

I post this question with a workaround in comment for three reasons :

• may be this can be useful to another user.
• the workaround is successful only if babel package and babel tikzlibrary are loaded together.
• somebody can surely provide a better answer than my workaround.

I don't see another question here like that but if i missed one, let me know and i delete mine.

With this MWE :

\documentclass{article}
\usepackage[frenchb]{babel}
\usepackage{tikz}
\usetikzlibrary{calc,babel,tikzmark}
\begin{document}
test\tikzmark{a}

Go to test\tikz[overlay, remember picture] \draw[->] to (pic cs:a);.
\end{document}


The document doesn't compile.

It compile if we remove babel in \usetikzlibrary or babel package.

Question : how can we make \tikzmark do its job with babel package AND babel library as well as with babel package and without babel library.

• Put "\makeatletter \let\tikzmark@active\tikzmark@nonactive \makeatother" after \usetikzlibrary{tikzmark} and the document compile fine. The correction added by @loopspace fail if we call babel in \usetikzlibrary and french option in Babel package. – sbm Oct 23 '16 at 10:24
• But your work around will fail if you don't use babel library. – Ulrike Fischer Oct 23 '16 at 13:31
• @UlrikeFischer. Sure, my workaround is needed only if we use babel package AND babel library. If not, the tikzmark package does its job perfectly. I've edited my question to be more accurate. – sbm Oct 23 '16 at 13:47

A new version of tikzmark is available for testing from github which hopefully gets rid of all the active/non-active/deactive/reactive semi-colon issues.

Turns out that there's an alternative form of the underlying \tikz command which avoids semi-colons. Instead of \tikz[...] ...; one can write \tikz[...]{...} and \tikzmark now uses this form.

Please test it by downloading tikzmark.dtx, running tex tikzmark.dtx, and putting the generated files somewhere that tex can find them. Then try it out with your documents and let me know if it works.

• Thank you for your time. I'll give it a try as soon as possible but it was my first use of tikzmark so i've not a lot of tests to do actually. I'll see for more tests when i'll find some time. I'll mail you my results to the adress wrote in the tikzmark doc. – sbm Oct 25 '16 at 10:30

The problem is the tikzmark tests whether or not the semicolon is active and proceeds accordingly. Now, the babel package makes the semicolon active when frenchb is active. tikzmark copes fine with that because the test is true and it proceeds on that basis. However, the babel TikZ library tries to handle active characters in code in TikZ pictures, too, so its attempts to avoid the issues caused by the babel package making the semicolon active conflict with the attempts of tikzmark to avoid the same issues. Essentially two things trying to avoid the problems end up counteracting each other.

Note that I do not understand this well enough to give a blow-by-blow account and even the above gesturing at one might be mistaken, but something like this seems to be going on.

The real issue here, I think, is that tikzmark should not assume that if the semicolon is active when \tikzmark is used, it will also be active inside tikzpictures because this will not typically be true if the babel TikZ library is used. Since this is a standard recommendation when documents use Babel configurations which make characters active, tikzmark essentially breaks code written in accordance with best practice.

I think tikzmark should test to see which active characters are being handled for code inside tikzpictures. This approach will not guarantee no breakage, but it should prevent breakage in standard cases where uses simply load the babel TikZ library and rely on it to set things up correctly.

You can workaround the problem by redefining \tikzmark. For example,

    \makeatletter
\renewcommand\tikzmark@outside[2][]{%
\ifnum\catcode\;=\active
\iftikz@handle@active@code
\let\tikzmark@next=\tikzmark@nonactive
\else
\let\tikzmark@next=\tikzmark@active
\fi
\else
\let\tikzmark@next=\tikzmark@nonactive
\fi
\tikzmark@next{#1}{#2}%
}
\makeatother


appears to solve the problem in the MWE, at least, and I hope should workaround it in real documents as well. You might also need to test whether TikZ is handling active characters in nodes. However, this should not matter in the standard case and would need, I think, to be customised for specific cases. In the standard case, where the babel library is used, active characters are handled in both code and nodes, so testing one is sufficient. Moreover, in the MWE, at least, handling active characters in nodes but not code did not reproduce the error, which is why I've tested specifically for the handling in code which causes the problem.

I would, however, recommend reporting this issue to tikzmark's author as there is almost certainly a much more elegant way to handle this issue than the one I've come up with here.

Complete example:

\documentclass[frenchb]{article}
\usepackage{tikz}
\usepackage{babel}
\usetikzlibrary{babel,tikzmark}
\makeatletter
\renewcommand\tikzmark@outside[2][]{%
\ifnum\catcode\;=\active
\iftikz@handle@active@code
\let\tikzmark@next=\tikzmark@nonactive
\else
\let\tikzmark@next=\tikzmark@active
\fi
\else
\let\tikzmark@next=\tikzmark@nonactive
\fi
\tikzmark@next{#1}{#2}%
}
\makeatother
\begin{document}
test\tikzmark{a}

Go to test%
\begin{tikzpicture}[overlay, remember picture]
\draw[->] (0,0) to ({pic cs:a});
\end{tikzpicture}%
.

\end{document}


• Consider it reported. My initial reaction is "bleugh, I'm fed up of the active/non-active dilemma". But I'll take a look and see what I can do. – Loop Space Oct 23 '16 at 22:32
• Oups ... i take the lat 30 min to wrote you an email of 10 words (but english words) so i don't saw your comment.. – sbm Oct 23 '16 at 22:46
• @LoopSpace You could just get rid of the test and tell people to use the babel TikZ library. After all, that's what people have to do to make all kinds of other things work. At least that way people could use tikzmark and the stuff which requires babel without having to fiddle with the lower level stuff, and it would no longer be your problem :-). – cfr Oct 24 '16 at 0:35
• @sbm Sorry, I think that's my fault. I didn't realise the answer you'd linked to was by the package author when I suggested reporting it and then I kind of got distracted. – cfr Oct 24 '16 at 0:37
• @cfr I'd appreciate you testing the latest version, available on github at github.com/loopspace/tikzmark – Loop Space Oct 24 '16 at 20:27