29

As my document grows, so does the number of drawings. I am using PGF/TikZ and each drawing is what is enclosed between \begin{tikzpicture} and \end{tikzpicture}. Every time the document is compiled, so is each of the drawings. I have recently noticed in connection with using the Lindenmayersystems library that memory is an issue! There must be a way of compiling drawings outside a document and have the document refer to the result of that compilation, instead of having the drawing's source code reside in the document. This would allow complex drawings to be compiled, with all available resources brought to bear on compiling that one drawing. Also, how could one have a large document with hundreds of drawings and not have a problem with memory?

I am using Windows 7, MiKTeX 2.9, TeXMaker 3.3.1.

Werner
  • 603,163
Reinhard Neuwirth
  • 3,329
  • if you are looking for ways to speed up your compiling time even beyond using tike' externalize capabilities (see Mark Everitt's answer), checkout my answer to this question. Here I explain how to precompile the preamble, so that it doesn't need to be compiled on every run. This has reduced the compiling time of my documents to < 1s for medium sized documents (~20 pages). Also, you could look into splitting up your document using \include and \includeonly, which allows you to split up a document and only compile a part of it in a sensible way. – romeovs Mar 06 '12 at 08:49
  • As Werner already answered, you can use the standalone class and package. The package provides a \includestandalone{file} which can insert either a file.pdf or file.tex. It can even compile the PDF from the standalone TeX file once and then use the PDF. This speeds things up very much (My thesis drops from 120s to 20s). – Martin Scharrer Apr 24 '12 at 19:31

2 Answers2

29

Use the TikZ external library for this. In your preamble place:

\usetikzlibrary{external}\tikzexternalize

You need to make sure that LaTeX is allowed to use external commands with -enable-write18 or -shell-escape. This will turn each TikZ figure into its own PDF image, and then TikZ knows to grab that instead (i.e. you won't need to change any of your code). For more information, see section 32 of the PGF/TikZ manual.

The benefit of this approach is that LaTeX typesets each figure individually, so that the memory overhead is broken down into smaller chunks, and you will be less likely to run out. You will also notice that each time you typeset it'll save some time after the figures have been generated.

qubyte
  • 17,299
  • Thanks Mark, I'll experiment with this and get back to you. – Reinhard Neuwirth Mar 06 '12 at 07:05
  • This works, but seemingly not for diagrams that use recursive calls, which I suspect is the case with pictures creating the Lindenmayersystem library. The TikZ manual's section on externalization makes comments in this regard (in a roundabout way) but does not offer a work-around other than suggesting to selectively disallowing externalization for pictures involving recursive calls. Am I on the right track with my comments? – Reinhard Neuwirth Mar 06 '12 at 09:32
  • It would be strange indeed if the library used recursive calls. It's considered a bad idea in general, but that's not to say that you're not right. Let me take a look at it and I'll see what I come up with. – qubyte Mar 06 '12 at 10:38
  • My mistake, I had forgotten the lindenmayersystem usetikzlibrary call. Your solution works fine and I am marking your answer as an ANSWER. And I like the fact that the document code looks the same with the source for each picture fully visible for ready reference. The standalone document class looks another promising option. If I get it to work I will mark this as an answer too. As an aside, I read somewhere that 4 indentations are used to cite code examples in COMMENTs, QUESTIONs, ANSWERs; how do I produce these indentations?, it's obviously not the TAB key. Thanks. – Reinhard Neuwirth Mar 06 '12 at 11:12
  • Four spaces to indent code. Note that only one answer may be marked as the accepted answer when you pick one, and pick the one you use (don't worry, I won't be offended if you don't pick mine!) I like to use external over the standalone class because with external your figures inherit all of the fiddly things that the document class of your main document does to the text. i.e. font and font size without extra effort. Standalone is a good way to generate external figures too, and can be useful for equations etc. if you want snippets for emails. – qubyte Mar 06 '12 at 11:19
  • Ah, inline code (for inside comments) needs backticks `` (one either side). – qubyte Mar 06 '12 at 11:20
  • let us continue this discussion in chat – Reinhard Neuwirth Mar 06 '12 at 11:48
  • Mark, I moved to chat, found the right room, saw our discussion so far, I am obviously logged in but cannot find the right keystroke to get to talk?! I am sure you have the answer to that one. – Reinhard Neuwirth Mar 06 '12 at 12:00
  • I noticed something quite unsettling when working with a couple of documents in a TexMaker session. Namely, a picture whose source is defined in document A shows up in documdent B. The source code for the picture meant to be in tht location in document B is completely ignored when compiling. I played with a few iterations to isolate the problem but nothing obvious showed up. What might I be doing wrong? – Reinhard Neuwirth Mar 09 '12 at 12:05
  • You shouldn't really be using the same folder for more than one document, just as general advice. The problem here is that TikZ automatically names the output images and looks for those to avoid making them. You can give the figures unique a prefix instead (the prefix must be different in the other document) with the command \tikzsetexternalprefix{unique_name_for_this_document} before the first TikZ figure. See the manual for more detail. Hint: The prefix can be a subdirectory, so you can keep all the figures together, e.g. \tikzsetexternalprefix{DocAFigures/}. – qubyte Mar 09 '12 at 13:50
  • Thanks Mark, I have taken your advise on board and am also currently experimenting with the standalone document class suggested by Werner. The attraction with that solution lies in the ability to establish a repository of drawings that may then be used in different documents.This is what I hope it will do anyway. – Reinhard Neuwirth Mar 11 '12 at 06:41
12

If memory is an issue (or even compile-time), you should consider creating the tikzpictures in a document of their own, combined with the standalone document class in its default preview mode (from the standalone documentation):

The class uses by default the preview package to create an output file which only contains the picture with no extra margins, page numbers or anything else.

Then, once the picture is created, include it in your document using graphicx's \includegraphics.

Alternatively, creating the tikzpicture on a blank page (using \pagestyle{empty}) allows you to use pdfcrop to trim any bordering whitespace. Subsequent inclusion in your main document is also done via \includegraphics.

Werner
  • 603,163
  • Thanks Werner, there is plenty of stuff here to experiment with. I'll let you know how I go. – Reinhard Neuwirth Mar 06 '12 at 07:06
  • 2
    Please note that the current version (v1.0) of standalone now uses the similar crop option by default, not preview. For TikZ graphics this will not have a negative impact, but a few positive ones (better XeTeX support, no trouble with unwanted paragraph breaks, ...). There is also now a mode that makes the standalone package (in the main file) compile and include the standalone files as images! Check out the v1.0 manual for more details. – Martin Scharrer Mar 06 '12 at 10:54