For better or for worse, this is currently a feature.
From Section 12.2.1 of pgfmanual
:
At the end of the environment, pgf
tries to make a good guess at the
size of a bounding box of the graphic and then resizes the picture box
such that the box has this size. To “make its guess,” everytime pgf
encounters a coordinate, it updates the bounding box’s size such that
it encompasses all these coordinates. This will usually give a good
approximation of the bounding box, but will not always be accurate.
It goes on to discuss certain situations where it is not accurate:
First, the line thickness of diagonal lines is not taken into account
correctly. Second, control points of a curve often lie far “outside”
the curve and make the bounding box too large.
While these specific points don't apply here, the second point shows that control points are considered coordinates for the purposes of bounding box computation, regardless of the actual stroked path's shape.
In much the same way, the shorten
keys modify the stroking of the path, not the coordinates defining it. If positive shorten
values are used, the bounding box is the same as if the path was completely drawn between the two endpoint coordinates. Then with negative shorten
values, the bounding box is also the same as if the path was drawn only between the two endpoint coordinates.
This behavior is illustrated in the example below. The computed bounding box is the same for each tikzpicture
, because it depends only on the coordinates used to define the path, not how it was actually drawn:
\documentclass[tikz,border=0.2cm]{standalone}
\newcommand{\boxit}{\draw (current bounding box.south west) rectangle (current bounding box.north east)}
\begin{document}
\begin{tikzpicture}
\draw[shorten >=-0.2cm, shorten <=-0.2cm] (0,0) -- (1,1);
\boxit;
\end{tikzpicture}
\begin{tikzpicture}
\draw[shorten >=0.2cm, shorten <=0.2cm] (0,0) -- (1,1);
\boxit;
\end{tikzpicture}
\end{document}

shorten
is an attribute of the path, shouldn't it be counted towards the bounding box?shorten
isn't really an attribute of the path.shorten >
andshorten <
were (I believe) intended only to be used with arrows (which is why they end with<
and>
). They fact that the path is shortened even when arrow heads are not explicitly applied is, I guess, an unintended side effect.shorten
was introduced as you kindly explained. However, from thetikz
user point of view,shorten
works the same as line widths, or caps or whatever. All the othertikz
-attributes are counted when computing the bounding box.shorten
is not and the manual is silent on the topic. Hence my question and my hoped for answer.