# How does TikZ clipping work? (the size ot the output)

Consider the following code

\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\clip (1,1) rectangle (9,9);
\foreach \x in {0,...,10}
\foreach \y in {0,...,10}
{ \draw (\x,\y) circle (1mm); }
\end{tikzpicture}
\end{document}


When compiled with pdfLaTeX, this gives a PDF file of 15 KB. Now let's change the number of circles (the new circles are outside the clipping area):

\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\clip (1,1) rectangle (9,9);
\foreach \x in {0,...,50}
\foreach \y in {0,...,50}
{ \draw (\x,\y) circle (1mm); }
\end{tikzpicture}
\end{document}


This gives a PDF which takes 139 KB. So the question is

Q: What does the clip command do with the content outside the clipping area? The above experiment suggests that all the circles are in fact there, but some of them are invisible. Is the clipping made on the side of the PDF viewer or on the side of the compiler? And is there a way to optimize the result by means of TikZ? If no, how should one proceed?

• From a first experiment I can confirm that the circles are not there. First, I got the same numbers as yours. But when I optimized the output PDF file for size reduction, I got about 14 and 16KB (nearly the same). It seems that the PDF stores redundant coordinates with no information. Something like an All-Zero matrix which has little meaning but occupies space. Running with latex-dvips, though, gives 7.2KB for both, which again confirms that the circles are not there. It seems a pure PDF issue, IMO, – AboAmmar Aug 6 '15 at 0:35
• @AboAmmar How does that establish that the circles are never there in the first place exactly? – cfr Aug 6 '15 at 0:53
• I've not tested but my guess is that all circles are actually encoded in the pdf file and the clipping command tells the viewer what to show. Acrobat Pro has an optimization feature able to remove from the encoding what is not shown (and this reduces the size of the file) but obviously, Tikz is not that sophisticated. – pluton Aug 6 '15 at 0:58
• ok, if you use pdflatex and open the output pdf file in Illustrator (for instance) you will be able to release the "clipping mask" and see that all circles are there. Same if you use latex -> dvips -> ps2pdf. IF you transform the ps file with acrobat distiller, the invisible circles are removed and the size of the final pdf, much smaller. – pluton Aug 6 '15 at 1:07
• @cfr From a second experiment I can tell the inverse. The sizes of DVI and PS show a similar ratio, which suggests that the circles are there. They didn't appear in Inkscape, though, or even in Acrobat professional in editing mode. – AboAmmar Aug 6 '15 at 1:30

If your question is about TikZ itself, then here is a simple test

\documentclass{article}
\usepackage{tikz}
\begin{document}

\message{^^J^^J break point A ^^J^^J}

\tracingmacros1
\begin{tikzpicture}
\path(0,0)(10,10);
\clip(1,1)rectangle(9,9);
\foreach\x in{0,...,10}
\foreach\y in{0,...,10}
\path(\x,\y);
\end{tikzpicture}
\tracingmacros0

\message{^^J^^J break point B ^^J^^J}

\tracingmacros1
\begin{tikzpicture}
\path(0,0)(10,10);
\clip(4,4)rectangle(6,6);
\foreach\x in{0,...,10}
\foreach\y in{0,...,10}
\path(\x,\y);
\end{tikzpicture}
\tracingmacros0

\message{^^J^^J break point C ^^J^^J}

\end{document}


I ended up with a 347858-line log file. And then I compared the two parts, finding that the only difference is about the clipping path itself, not what follows. So we may conclude TikZ does not do any clipping-reduction. It is other bottom drivers that can do the optimization. (They may or may not, you see the results vary in comments)

To be more explanative, a \clip inside TikZ is first equivalent to \path[clip], and then translate to an encoded path followed by an operator (e.g. \pgfusepath{clip} or W). TikZ then shipped-out these stuff and forget it. In general, we cannot expect TikZ to do the optimization using its poor arithmetic.