# shorten and bounding box in tikz; possible bug?

While working out this answer, I found out that shorten options do not count towards computing the bounding box of a tikzpicture. Case in point:

\documentclass{standalone}
\usepackage[]{tikz}
\begin{document}
\begin{tikzpicture}
\draw[shorten >=-3cm, shorten <=-3cm] (0,0) -- (1,1);
\draw (0,0) circle (1pt);
\draw (1,1) circle (1pt);
\end{tikzpicture}
\end{document}


The manual does not specify whether this should be the case or not.

Question: bug or feature?

• What do you expect as an answer: "Yes, bug" or "Yes, feature"? – Daniel Oct 4 '13 at 9:24
• @Daniel: I hope “yes, bug”. I expect “Yes, maybe” :) Seriously, though, if shorten is an attribute of the path, shouldn't it be counted towards the bounding box? – Koji Oct 4 '13 at 9:47
• shorten isn't really an attribute of the path. shorten > and shorten < 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. – Mark Wibrow Oct 4 '13 at 9:54
• @MarkWibrow I understand that shorten was introduced as you kindly explained. However, from the tikz user point of view, shorten works the same as line widths, or caps or whatever. All the other tikz-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. – Koji Oct 4 '13 at 10:00
• negative shortens are features as the name implies. – percusse Oct 4 '13 at 10:11

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}