Pour la rédaction de gros documents, tels qu’un manuscrit de thèse, il est élémentaire de ne compiler que les parties sur lesquelles on travaille (grâce notamment à la commande \includeonly). Pour gagner encore en temps de compilation, il est préférable d’externaliser les figures TikZ pour n’avoir à les compiler qu’une fois. Toutefois, certaines précautions sont alors à prendre pour appliquer ces deux méthodes en même temps.

PGF v3.0.0.

Avant de commencer, je vais profiter de ce billet pour expliquer le nouveau fonctionnement de l’externalisation des figures depuis la version 3.0.0. de PGF. Jusqu’alors, pour mettre à jour une figure déjà compilée, il fallait soit supprimer le pdf correspondant, soit rajouter devant la figure à mettre jour :

\tikzset{external/remake next}

La version 3.0.0 utilise un suivi du code source pour y déceler des modifications. Ainsi, à la première compilation, le pdf de la figure sera créé (ainsi que les autres fichiers de compilation), mais un hash md5 sera aussi calculé sur le contenu du tikzpicture, puis enregistré dans un fichier .md5. A la seconde compilation, si le code n’a pas changé, alors l’empreinte MD5 non plus, donc PGF se contentera d’importer le pdf.

Cette nouvelle fonctionnalité permet donc a priori de s’affranchir des deux méthodes proposée plus haut, avec toutefois une limite : le hash étant fait sur le code brut, il ne gère pas les dépendances. Donc si le rendu dépend d’options données dans le préambule, PGF ne verra pas de différence si vous changez ces options. Le cas échéant, la commande donnée ci-dessus reste valable, ou bien vous pouvez supprimer le fichier md5 pour forcer la recompilation.

Externalisation : éviter les conflits

Un peu de rangement

Déjà, si vous travaillez sur un gros document, alors peut-être qu’une bonne idée serait de définir un emplacement spécifique pour les fichiers externalisés, ce qui limitera le nombre de fichiers dans le dossier de compilation (pour info, pour mon manuscrit de thèse, j’ai déjà plus de 80 fichiers de compilation, donc pas la peine d’en rajouter avec les figures externalisées…).

Pour définir un dossier de destination pour toutes les figures externalisées, il suffit de préciser un « préfixe » pour les figures :

\tikzexternalize[prefix=TikZ/]

Ainsi, les figures seront automatiquement enregistrées dans le dossier TikZ.

Noms différents pour chaque partie du document

Revenons sur le problème initial : le cas de l’utilisation conjointe de \include et \includeonly.

Mettons que vous travaillez sur le chapitre 1, qui contient une ou plusieurs figures TikZ. Lors de la compilation, les figures s’appelleront donc Main-figure0.pdf, Main-figure1.pdf etc.

Si vous arrêtez de travailler sur ce chapitre, pour vous intéresser au second, alors, par défaut, TikZ va utiliser les mêmes noms pour les figures du second chapitre. Comme le hash va être différent, alors il va écraser toutes les figures présentes, ce qui est quand même un peu dommage.

Pour éviter ça, vous avez deux solutions : la première étant de définir vous-même le nom de chaque fichier à externaliser, avant chaque tikzpicture :

\tikzsetnextfilename{figureexternalisee}

Problème : si vous avez 50 figures différentes, ça va vous saouler de donner un nom à chaque fois, donc vous serez probablement tentés de laisser TikZ gérer ça. La deuxième solution consiste donc à préciser un nom par défaut, différent pour chaque chapitre :

{\tikzsetfigurename{TikZ/1-TikZ_}
	\include{Chap1}
}
{\tikzsetfigurename{TikZ/2-TikZ_}
	\include{Chap2}
}
{\tikzsetfigurename{TikZ/3-TikZ_}
	\include{Chap3}
}

Ainsi, toutes les figures du premier chapitre seront nommées 1-TikZ0.pdf, 1-TikZ1.pdf etc., celles du second chapitre nommées 2-TikZ0.pdf, 2-TikZ1.pdf etc. etc.

Et pourquoi ça marcherait pas avec un préfixe différent pour chaque chapitre ?

L’avantage de la commande \tikzfigurename est qu’elle réinitialise la numérotation des fichiers (à 0). Avec l’utilisation du préfixe, la numérotation des fichiers d’un chapitre dépendrait donc des chapitres précédents, ce que l’on ne souhaite pas puisqu’on veut pouvoir compiler indifféremment un ou plusieurs chapitres !

Pour aller plus loin

La doc officielle bien sûr !
(pages 615 à 625 pour les options d’externalisation)

Bonnes compilations !