# How is the positioning of labels attached to arrows calculated by the tikz-cd package?

I recently bumped into a small problem while using the tikz-cd package. It was about the positioning of the labels attached to certain arrows. One of the users in chat was friendly enough to point out to me that the positioning can be manually controlled using pos=<fraction>.

Upon implementing this fix, I discovered that the behavior as I varied my input for <fraction> was quite remarkable and counter-intuitive. I would have naively expected for the fraction to correspond, in the obvious way, to the fraction of arrow-length. Some experimenting shows that, for straight arrows, this indeed seems to be the case. However, for bent arrows it doesn't seem so simple. As a (minimal working) example, consider the following:

\documentclass{article}
\usepackage{tikz-cd}
\begin{document}
$\begin{tikzcd} A \arrow[r,bend left=30,"\pi" pos=<fraction>]&B \end{tikzcd}$
\end{document}


Inserting .4 and .6 for <fraction> yields the following two outputs:

which certainly do not correspond to the label being placed 40% and 60% along the length of the arrow. My (obvious) question is: What do the numbers represent? How are they used to determine where to place the labels (especially in the apparently non-trivial bent-arrow case)?

The maintainer of the package has responded to a message about this problem---it turns out to be intended behavior.

I would consider that a bug and would advice you to report this. You can use the following example:

% arara: lualatex

\documentclass{article}
\usepackage{tikz-cd}
\usepackage{lua-visual-debug}

\begin{document}
\begin{tikzcd}
A \arrow[bend left=60,"\mid" pos=.1,"\mid" pos=.2,"\mid" pos=.3,"\mid" pos=.4,"\mid" pos=.5,"\mid" pos=.6,"\mid" pos=.7,"\mid" pos=.8,"\mid" pos=.9]{r} & B\\
A \arrow[bend left=30,"\mid" pos=.1,"\mid" pos=.2,"\mid" pos=.3,"\mid" pos=.4,"\mid" pos=.5,"\mid" pos=.6,"\mid" pos=.7,"\mid" pos=.8,"\mid" pos=.9]{r} & B\\
A \arrow["\mid" pos=.1,"\mid" pos=.2,"\mid" pos=.3,"\mid" pos=.4,"\mid" pos=.5,"\mid" pos=.6,"\mid" pos=.7,"\mid" pos=.8,"\mid" pos=.9]{r} & B
\end{tikzcd}
\end{document}


I would report it to tikz-cd as this seems not to be a problem of TikZ itself. Just see this (sorry, ugly) code:

% arara: pdflatex

\documentclass{article}
\usepackage{tikz-cd}
\usetikzlibrary{positioning}

\begin{document}
\begin{tikzpicture}
\node (1) {A};
\node (2) [right = of 1] {B};
\path[every node/.append style=above] (1) edge[bend left=60] node [pos=.1] {$\mid$} node [pos=.2] {$\mid$} node [pos=.3] {$\mid$} node [pos=.4] {$\mid$} node [pos=.5] {$\mid$} node [pos=.6] {$\mid$} node [pos=.7] {$\mid$} node [pos=.8] {$\mid$} node [pos=.9] {$\mid$} (2);
\end{tikzpicture}
\end{document}


It seems that tikz-cdplaces the label box to the right of the insertion point instead of centring it at that point.

Here is a code that allows the comparison with pstricks (its psmatrix environment is an alternative to tikz-cd). I successively placed the label box centred (default), to the left and to the right of the insertion point.

\documentclass{article}
\usepackage{tikz-cd}

\usepackage{pst-node}
\usepackage{auto-pst-pdf}

\begin{document}
$\begin{tikzcd} A \arrow[r,bend left=30,"\pi" pos=0.6]&B \end{tikzcd}$

\psset{linewidth=0.6pt, arrows=->, arrowinset=0.15, nodesepA=4.5pt, nodesepB=4.5pt, arcangle=35, shortput=nab, tpos=0.6, labelsep=3pt}
$\begin{psmatrix}[colsep = 1.15cm] [name=A] A & [name=B] B \ncarc{A}{B}^{\scriptstyle\pi} \end{psmatrix}$%

$\begin{psmatrix}[colsep = 1.15cm] [name=A] A & [name=B] B \ncarc{A}{B}^{\makebox[0pt][r]{\scriptstyle\pi }} \end{psmatrix}$%

$\begin{psmatrix}[colsep = 1.15cm] [name=A] A & [name=B] B \ncarc{A}{B}^{\makebox[0pt][l]{\scriptstyle\pi }} \end{psmatrix}$%
\end{document}


• Sorry, but what has this to do with the question? – egreg Oct 9 '15 at 17:39
• I explained how tikz seems to position the label box (by the left-hand side, not by its centre, nor its right-hand side), as can be clearly seen from the comparison with what we can produce with pstricks. It confirms @Larifari's point of view: this is a bug, as the sensible positioning would be to use the centre. – Bernard Oct 9 '15 at 17:55