I share similar feelings with the OP, and find the externalization solution good, but for sure not perfect. For example, in addition to the con the the OP pointed, I would like to add two issues:
- If one inserts a new figure, somewhere in the middle of the document, then
tikz will re-build all the following ones, although they were not changed.
- Editing the image is somehow annoying. You don't want to edit your
tikz image as part of a huge document.
I'm not familiar enough with the standalone package, so I cannot really judge, but if I understand correctly, it won't avoid compiling all the image when the main document is compiled.
Following is an outline of an idea that I tried to implement. So far it is not working, but it might be an idea for others...
Setting
Assume the you have the following structure:
- project
|- main.tex
|- tikz-images
|- tikz1.tex
|- tikz2.tex
and you build using latexmk.
Idea
Turn the tikz images into standalone documents, build their corresponding pdf's using make and include the pdf(!) in the document. This way, whenever a new tikz image is created, all you need to do is add a target to the makefile in tikz-images.
Problems will come regarding the compilation using latexmk who will not(!) be aware of changes to tikz1.tex.
Implementation
First, the files in tikz-images should have the extension .tikz, reserving the .tex extension for a common preamble to be included in all figure source codes. This will help you to keep the same font & Co. settings of the main document. Then, in project create the following makefile:
TIKZDIR = tikz-figures
TIKZ_FILES = $(wildcard $(TIKZDIR)/*.tikz)
PDFTIKZ_FILES = $(patsubst %.tikz,%.pdf,$(TIKZ_FILES))
$(TIKZDIR)/%.pdf: $(TIKZDIR)/%.tikz $(TIKZDIR)/common-preamble.tex
cd $(TIKZDIR); \
pdflatex $$(basename $<)
.PHONY : FORCE_MAKE
all : main.pdf
main.pdf : main.tex FORCE_MAKE ${PDFTIKZ_FILES}
latexmk main.tex
This way, calling make main.pdf in project will first build the tikz images (incase they were changed, or they are missing) and then latexmk will take care of the rest.
This approach, once fully implemented, could have two main advantages:
- Developing the pictures can be quicker and be carried out regardless of the main document. Thus, faster.
- Building of the document can be quicker as well since it will merely include ready PDFs.
Problems:
- As I mentioned, completing the implementation of the
makefile in `project.
- One of the most important benefits of
externalization library of tikz is that you get the same setting for the images (fonts for example). To have this also in the proposed approach, something has to be done.
- Improve the
makefile of the tikz images.
externallibrary? – Jake Sep 10 '12 at 18:24externallib and thestandalonepackage. Note that theexternallib now detects changes inside of the tikzpicture environment using MD5 checksums (using the CVS unstable). – Christian Feuersänger Sep 10 '12 at 18:27standalonemakes things much faster, because you can include the TikZ pictures as images. There is an auto-recompile feature. But, if you mindexternalyou might mindstandaloneas well. – Martin Scharrer Sep 10 '12 at 18:28standalonedocument class will give us many advantages: (1) make the preamble of the main cleaner because macro definitions that are specific to a certain diagram will only be placed in the preamble of the input file of the corresponding diagram, (2) which in turn, etc. – kiss my armpit Sep 10 '12 at 18:40forest(usingforest's support) or with things using backgrounds (remember picture, overlays etc.). So externalisation only took me, at least, so far... – cfr Jul 15 '14 at 00:28