17

Maybe this is expected behaviour, but it's not documented in the manual, and it certainly surprised me.

When you use the draft class option and use the tikz external library, all Tikz pictures are replaced by a box with the name of the externalized graphic.

MWE:

\documentclass[draft]{article}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize
\begin{document}
\begin{tikzpicture}
  \draw (0,0) circle [radius=1];
\end{tikzpicture}
\end{document}

result with draft

The fact that it displays the correct filename leads me to think it's the external library doing this, because whilst I know that pgf itself does a similar thing with the draft option, I wouldn't expect it to know the filename (and anyway, I haven't loaded pgf directly, and I think it only obeys draft when called directly.)

However, commenting out the \tikzexternalize line gives the picture.

Result without draft

I'm not saying that this behaviour wouldn't often be useful! However, it's not what I'd prefer in what I'm working on, and as it isn't documented I don't know what I can do about it.

I can try and work around it, and not use draft but it's in a big document that already does several different things depending on whether draft is set.

What are my options?

10
  • Why wouldn't you expect it to know the filenames? Mar 9, 2012 at 19:14
  • 1
    draft mode effect graphics that included form external files, which is what \tikzexternalize does, and does not effect the tikzpicture environment as it is not a graphic that is included, but rather just some code that gets typeset. Mar 9, 2012 at 19:19
  • I meant that I wouldn't expect the basic pgf to know the filenames of the externalized pictures (e.g. main-texfile-figure0), since they're generated by the external library. That wasn't very clear, I'll edit it. Mar 9, 2012 at 19:19
  • 1
    @JosephCooper The complicated bit that external does is to create the graphic in the first place. But once it is created then it is included back in via \includegraphics and what you are seeing is the effect of the draft option on the graphicx package. However, I would say that this is definitely Not Obvious Behaviour and there's no reason why one would guess that (especially as graphicx is loaded via pgf so one might not know it was being used). Mar 9, 2012 at 19:44
  • 2
    @PeterGrill You should write that as an answer. Although when you know then the answer is simple, I wouldn't consider it an obvious thing to guess if you don't know so it's a useful question to have here, and therefore one that should be answered properly. Mar 9, 2012 at 19:45

2 Answers 2

14

There is a "fix" for the underlying problem as proposed by Christians comment:

TikZ does not use \includegraphics for externalized figures as stated in the documentation but \pgfimage{figure0.eps}. This is not aware of the draft mode. This can be changed in the beginning of the document with

\pgfkeys{/pgf/images/include external/.code=\includegraphics{#1}}

leading to

\documentclass[draft]{article}
\usepackage{tikz}
\usetikzlibrary{external}

\pgfkeys{/pgf/images/include external/.code=\includegraphics{#1}}

\tikzexternalize
\begin{document}
\begin{tikzpicture}
  \draw (0,0) circle [radius=1];
\end{tikzpicture}
\end{document}

which renders the "draft-box" for the missing image in the correct size.

2
  • Better late than never! This answer is definitely the answer to the concrete question. I load my graphicx package with the "final" option, as I do not wish to have blanks for images - I use draft mode to change margins and to show fixme annotations.
    – Clausen
    May 7, 2014 at 23:50
  • Does someone know if this should work with XeTeX? I have some problems here.
    – buhtz
    Oct 31, 2015 at 13:41
13

Documentclass [draft] option:

Using the optional parameter [draft] to the \documentclass has two main uses:

  • indicate overfull hbox by a vertical bar in the margin
  • graphics that are included from external sources do not get displayed (only an outline of the box is displayed). A similar effect can be achieved using \usepackage[demo]{graphicx}.

This has no effect on the tikzpicture environment within a document as that is not considered an external graphic. Its content is typeset and displayed in the output, just as the content of any other environment would be.

TikZ Externalization Library:

The main purpose of \usetikzlibrary[external] and the associated \tikzexternalize is to speed up compile times by converting each tikzpicture into a separate external graphic which is then imported with \includegraphics. Hence, the behavior you are seeing.

This can be disabled on a per use basis by using \tikzexternaldisable within a group:

{\tikzexternaldisable% disable within a group
\begin{tikzpicture}
  ...
\end{tikzpicture}
}

or disabling externalization before the tikzpicture and re-enabling it following the picture:

\tikzexternaldisable% disable outside of a group
\begin{tikzpicture}
  ...
\end{tikzpicture}
\tikzexternalenable% should re-enable at end.

Disabling will probably be required for cases where there are nested tikzpicture environments.

The MWE example below illustrates these and yields:

enter image description here

Code:

\documentclass[draft]{article}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize
\begin{document}

{\tikzexternaldisable% disable within a group
\begin{tikzpicture}
  \draw [blue, ultra thick, fill=red!10] (0,0) circle [radius=1] node {1};
\end{tikzpicture}
}

\tikzexternaldisable% disbale outside of a group
\begin{tikzpicture}
  \draw [red, ultra thick, fill=blue!10] (0,0) circle [radius=1] node {2};
\end{tikzpicture}
\tikzexternalenable% should renable at end.

\begin{tikzpicture}
  \draw [black, ultra thick,fill=yellow!20] (0,0) circle [radius=1] node {3};
\end{tikzpicture}
\end{document}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .