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.

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.

Why wouldn't you expect it to know the filenames?
–
Yiannis LazaridesMar 9 '12 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.
–
Peter GrillMar 9 '12 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.
–
Joseph CooperMar 9 '12 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).
–
Loop SpaceMar 9 '12 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.
–
Loop SpaceMar 9 '12 at 19:45

2 Answers
2

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

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.
–
ClausenMay 7 '14 at 23:50

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.