12

While designing a title page in TikZ I noticed a somewhat unwanted behaviour. When I use the externalize and the overlay option for a tikzpicture the output is just empty.

MWE:

\documentclass{book}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize[prefix=tikz/]

\begin{document}
\begin{tikzpicture}[remember picture,overlay]
    \node at (1,1) {test2};
\end{tikzpicture}
\end{document}

Removing the two lines \usetikzlibrary{external}, tikzexternalize[prefix=tikz/] gives the wanted behaviour. This is not critical since I can just specify, that this particular image (the title page) should not be externalized, but I think this is somehow unwanted, at least not expected. Is there a proper workaround?

epR8GaYuh
  • 2,432
manthano
  • 1,040
  • 6
  • 19

1 Answers1

7

This problem has nothing to do with how many times you need to compile. Removing remember picture does not help. Even if you force TikZ to remake pictures by /tikz/external/remake next and compile a thousand times it will still show nothing.

The true problem is that when an externalized picture is included back to the original document, \includegraphics \pgfimage pdfTeX will clip it by its bounding box.

Since pictures with overlay has a bounding box of size zero, everything will be clipped. (See the next section)

To prove this, consider the following example:

\documentclass{book}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize

\begin{document}
\tikz{
    \draw circle(5);
    \pgfresetboundingbox
    \path(-4,-4)(4,4);
}

%\includegraphics{\jobname-figure0.pdf}

\end{document}

It will gives you the clipped circle, which is exactly the same as if you open \jobname-figure0.pdf in any pdf reader.

A more interesting example

Removing \path(-4,-4)(4,4);, you will get

This seems to contradict my theory: without (-4,-4) and (4,4) the bounding box should be of size zero. But guess what: if you open \jobname-figure0.pdf you will see exactly the same arc.

diving into PDF

  • While \jobname-figure0.pdf is generated, it has a /MediaBox entry, which is rouphly the size of the page.
    • If, in TikZ, \pgfresetboundingbox or [overlay] is used, a default value of [0 0 144 144] is used. Here 144 means 2 inches. This number comes from nowhere.
    • If the bounding is set explicitly as, say, \path(-1in,-1in)(2in,2in); then it is [0 0 216 216]. Here 216 means 3 inches.

  • While pdfTeX includes the external image in the main file, it

    takes the BoundingBox of a pdf file from its /CropBox if available, otherwise from its /MediaBox.

    • For \pgfresetboundingbox and [overlay]: the /BBox entry is [0 0 144 144] .
    • For \path(-1in,-1in)(2in,2in);: the /BBox entry is [0 0 216 216] .

  • When PDF renderer renders the file, it

    clips according to the form dictionary’s /BBox

    • For \pgfresetboundingbox and [overlay], everything outside (0,0) rectangle (2in,-2in) will be clipped . There is a negetive because the y-axis points down in PDF.
      • To prove this, try to replace \node at (1,1) {test2}; by ±1.
    • For \path(-1in,-1in)(2in,2in);: it is clipped with respect to the that rectangle.

Possible workaround?

There might be a way to tell pdfTeX not to set the /Bbox entry. This is quite hopeless.

The other possibility is to rewrite TikZ externalizing library so that it will produce an external image with its native bounding box. But keep the information of user-specified bounding box and use it as the image is included back.

(This could be really hard. For exmple if \tikzmark is used, what the native bounding box should be? )

For now, a easy workaround is not to export the image

\documentclass{article}
    \usepackage{tikz}
        \usetikzlibrary{external}\tikzexternalize
\begin{document}
    \tikzset{external/export next=false}
    \tikz[remember picture,overlay]\draw(0,0)--(current page.center);
\end{document}
Symbol 1
  • 36,855
  • You are right about the clipping, but I'm not sure it is \includegraphics doing the clipping. – cfr Dec 01 '16 at 12:49
  • 1
    overlay doesn't seem to set the bounding box to zero. If I try \begin{tikzpicture}[overlay] \node [circle, draw, fill=white, minimum size=50mm] {}; \end{tikzpicture}, I don't get nothing. Instead, I get an improperly centred circle - or, rather, I get the south-west quadrant of the circle as you do with your example. – cfr Dec 01 '16 at 13:03
  • @cfr I fixed my statement. Please see the update. I hope that the only remaining question is the origin of 144. – Symbol 1 Dec 01 '16 at 21:28
  • You still say it is clipped when \includegraphics is used to bring it back into the document, but the external image is already clipped when \includegraphics has no involvement. Is the point that the viewer clips the PDF in the same way? – cfr Dec 01 '16 at 21:56
  • How do you know 144 is 2" and 216 is 3"? Have you tried this with XeLaTeX? – cfr Dec 01 '16 at 22:05
  • @cfr Well, my point is, there was a hope that \includegraphics can bring back the invisible part of an external PDF file. This hope comes from the fact that when I was using image editing programs, I can see the part that exceeds the canvas. (And after all it is not \includegraphics because PGF uses its own \pgfimage instead.) – Symbol 1 Dec 01 '16 at 22:07
  • 1
    Purely guess. I guess PDF use PostScript Point, and 2 inches is 5.08 cm, which is the radius of our circles. I tried just pdfTeX because I need \pdfcompresslevel etc. – Symbol 1 Dec 01 '16 at 22:09
  • Well, mine was 25mm, but fair enough. XeLaTeX is interesting, though ;). – cfr Dec 01 '16 at 22:38