A line of length \textwidth in TikZ

Question

Why does the following latex document:

\documentclass{minimal}
\usepackage{tikz}

\begin{document}
    \noindent
    \begin{tikzpicture}
        \draw (0,0) -- (\textwidth,0);
    \end{tikzpicture}
\end{document}

give an overfull \hbox of 0.4pt? The line cap option has no effect. An ultra thick line gives a larger overfull \hbox of 1.6pt.

Is there a better (more TikZ-like) way to achieve the same effect, i.e., draw a line to the edge of the text box? Ideally I'd like to do this without scaling the figure.

Answer 1

The code can be adapted very easily to not get the warning anymore:

\documentclass{minimal}
\usepackage{tikz}

\begin{document}
    \noindent
    \begin{tikzpicture}
        \draw[line cap=rect] (0,0) -- (\linewidth-\pgflinewidth,0);
    \end{tikzpicture}
\end{document}

EDIT: I think I also have an explanation: Each time tikz draws a line, it uses 2 bounding boxes (cf. PGF manual v 2.10 - page 579):

As a side-effect, the path construction commands keep track of two bounding boxes. One is the bounding box for the current path, the other is a bounding box for all paths in the current picture.

Section 7.13 details these parameters.

What I think is happening, is that regardless of the way how the line ends (line cap), its bounding box protrudes by \pgflinewidth beyond the edge of the text area by this length. This is probably necessary to accommodate the whole line in case of nicely rounded line caps. Since this requires in fact .5\pgflinewidth on each end and the bounding box of the line starts at exactly (0,0) the overhang will be \pgflinewidth at the end of the line.

Answer 2

This is an answer to the first question: Why does TikZ do that?

To look at this we need to understand how TikZ works internally. The following is a very simplified (but I hope correct) account of how TikZ code gets processed:

1. Frontend code (i.e. TikZ code) is translated to “basic layer” code (i.e. pgf code). For example,

    \draw (0,0) -- (\textwidth,0);
   

   (basically) becomes

    \pgfmoveto{\pgfpoint{0pt}{0pt}}
    \pgflineto{\pgfpoint{\textwidth}{0pt}}
    \pgfusepath{stroke}
   

2. The pgf code constructs a path. A path is a mathematical object and so everything is represented as having infinitely small line width. Thus the first two \pgf... lines above will result in a path that consists just of one line segment. The bounding box is calculated in this step by simply looking at the extremal values of each part of the path. So in this example, the bounding box of the path will be rectangle of width \textwidth and height 0.

3. The path is then “used” with \pgfusepath and similar commands. This translates it into drawing commands of the output format (e.g. PostScript or PDF).

The problem with this approach is that the bounding box might change between steps 2 and 3 as stroking a path with a positive line width will change its size. However pgf never gets the information of the final bounding box, because the stroking is only done at the level of the viewer (the PDF contains the information of the path and the line width and then the PDF viewer has to figure out how to display that correctly).

Considering the line width while calculating the bounding box in step 2 is I think significantly harder than just calculating the bounding box of the path itself. Thus pgf takes the easy way out: after finishing the second step, it just adds half the line width in every direction to the bounding box. This is done in pgfcorepathusage.code.tex:

  %
  % Check whether the path is stroked. If so, add half the line width
  % to the bounding box.
  %
  \ifpgf@relevantforpicturesize%
    \ifx\pgf@up@stroke\pgfutil@empty%
    \else%
      \ifdim\pgf@picmaxx=-16000pt\relax%
      \else%
        \pgf@x=\pgf@pathminx\advance\pgf@x by-.5\pgflinewidth%
        \ifdim\pgf@x<\pgf@picminx\global\pgf@picminx\pgf@x\fi%
        \pgf@y=\pgf@pathminy\advance\pgf@y by-.5\pgflinewidth%
        \ifdim\pgf@y<\pgf@picminy\global\pgf@picminy\pgf@y\fi%
        \pgf@x=\pgf@pathmaxx\advance\pgf@x by.5\pgflinewidth%
        \ifdim\pgf@x>\pgf@picmaxx\global\pgf@picmaxx\pgf@x\fi%
        \pgf@y=\pgf@pathmaxy\advance\pgf@y by.5\pgflinewidth%
        \ifdim\pgf@y>\pgf@picmaxy\global\pgf@picmaxy\pgf@y\fi%
      \fi%
    \fi%
  \fi%

Of course this approximation might also be wrong in the other direction, as the following example shows:

\documentclass{article}
\usepackage{tikz}

\begin{document}
\begin{tikzpicture}
    \draw[line width=1cm] (0,0) -- (5,0) -- (0,2);
    \draw[red] (current bounding box.south west) rectangle (current bounding box.north east);
\end{tikzpicture}
\end{document}

Exercise: Compute the correct bounding box for this example.

Answer 3

A possibility to get a line with a length equal to \linewidth or \textwidth without overfull box is to use a clip or, as I wrote in a comment, to modify the bounding box.

\documentclass{minimal}
\usepackage{tikz}

\begin{document}
    \noindent
    \begin{tikzpicture} 
        \draw (0,0.1) -- (\linewidth-\pgflinewidth,0.1); 
        \clip (0,-5\pgflinewidth) rectangle (\textwidth,5\pgflinewidth);
        \draw (0,0) -- (\textwidth,0);
    \end{tikzpicture}
\end{document} 

Remark : It's not another possibility because with \draw (0,0) -- (\linewidth-\pgflinewidth,0); the length is not correct.

Explanations :

I think that TikZ (or PGF with the basic layer) needs to be efficient at each step of the drawing. Firstly, the dimensions must be accurate enough and it's difficult with TeX, but Tikz needs to be fast enough. It's complicated like Caramdir shows in a example to calculate exactly the bounding box in all the cases. Some rules are necessary to avoid being too slow and to get correct results.

1) When you draw a simple line you get a complicated bounding box

This picture shows the problem at each side of the picture. In this first picture I used line join=round but in the next I used the values by default.

2) why add 0.5\pgflinewidth

When you draw a rectangle for example, the width is determined from the middle of line (with rounded corners or not). So I think that the main rule is to add 0.5\pgflinewidth in all the cases.

3) Now why clip is fine to get exactly what you want

When a clip is used, the line width is not used

4) Conclusion. I think it's preferable to avoid very large width for the line and in some cases it's necessary to have this question in memory to get exact dimensions.

Here is the code for experimentation:

\documentclass{minimal}
\usepackage{tikz}

\begin{document}

\begin{tikzpicture} 
    \draw[help lines] (0,0) grid (1,1);  
    \draw[line width=.4cm,opacity=.2,line join=round] (0,0) -- (1,0) -- (0,1);
    \draw[red] (current bounding box.south west) rectangle (current bounding box.north east);
\end{tikzpicture}

\vspace*{12pt}   
\begin{tikzpicture} 
    \draw[help lines] (0,0) grid (1,1);  
    \draw[line width=.4cm,opacity=.2] (0,0) -- (1,0) -- (0,1);
    \draw[red] (current bounding box.south west) rectangle (current bounding box.north east);
\end{tikzpicture}   

\vspace*{12pt}
 \begin{tikzpicture}
  \draw[help lines] (0,0) grid (2,1);
    \draw[line width=.4cm,rounded corners,opacity=.2] (0,0) rectangle (2,1);
    \draw[red] (current bounding box.south west) rectangle (current bounding box.north east);
\end{tikzpicture}

\vspace*{12pt}
 \begin{tikzpicture}
  \draw[help lines] (0,0) grid (2,1);
    \draw[line width=.4cm,opacity=.2] (0,0) rectangle (2,1);
    \draw[red] (current bounding box.south west) rectangle (current bounding box.north east);
\end{tikzpicture} 

\vspace*{12pt}    
\begin{tikzpicture}
  \draw[help lines] (0,0) grid (2,1);
    \clip (0,0) rectangle (2,1);  
    \draw[line width=.4cm,opacity=.2] (0,0) rectangle (2,1);
    \draw[red] (current bounding box.south west) rectangle (current bounding box.north east);
\end{tikzpicture}  

\end{document} 

Answer 4

The first two tikzpictures show the bug calculation of the bounding box.

The third tikzpicture answers the question via a filled rectangle. ;-)

\documentclass{minimal}
\usepackage{tikz}

\begin{document}
\begin{tikzpicture}[outer sep=0pt,inner sep=0pt]
  \draw[line cap=butt,line width=10pt] (0,0) -- (1,0);
  \draw[line width=1pt,red]
  (current bounding box.south east)
  rectangle
  (current bounding box.north west);
\end{tikzpicture}

\begin{tikzpicture}[outer sep=0pt,inner sep=0pt]
  \draw[line cap=round,line width=10pt] (0,0) -- (1,0);
  \draw[line width=1pt,red]
  (current bounding box.south east)
  rectangle
  (current bounding box.north west);
\end{tikzpicture}

\noindent
\begin{tikzpicture}
  \fill (0,0) rectangle (\linewidth,1pt);
\end{tikzpicture}
\end{document}

Another solution uses trim left and trim right to compute good (horizontal) bounding box without clipping (as pgf manual says, "[...]baseline, trim left and trim right are currently the only supported way of truncated bounding boxes which are compatible with image externalization[...]").

\documentclass{minimal}
\usepackage{tikz}

\begin{document}
\noindent
\begin{tikzpicture}[trim left=0cm,trim right=\linewidth]
  \draw (0,0) -- (\linewidth,0);
\end{tikzpicture}

\end{document}