Une méthode pour générer ses figures : automatisation et traduction
L’avantage de faire une thèse est de réfléchir à ses méthodes de travail et d’organisation. Dans les productions scientifiques, les figures prennent une place très importante et requièrent donc d’y consacrer du temps.
Mon objectif est d’optimiser au maximum la production de mes figures. J’ai choisi d’utiliser quasi-exclusivement LaTeX pour mes figures pour des raisons de qualité, du coté “codage” (les avantages de l’approche code vont être largement mis en exergue ici) et de manipulation de formats.
Sources des figures
Mes figures sont de trois types :
- Chemfig pour les formules chimiques (.chem)
- Tikz pour les schémas (.pgf)
- Gnuplot avec la sortie Lua/Tikz (.plt -> .tikz)
Production des figures
La production des figures est réalisée à l’aide d’un makefile et de deux scripts shells. Un premier script nommé tikzmaker encapsule le fichier tikz (.pgf) avec une entête Latex en utilisant le paquet standalone, ce qui donne un .tex. De même, un script chemmaker transforme mes .chem en .tex.
Gnuplot se charge de produire un fichier .tikz à partir du fichier .plt. Ce fichier tikz passe aussi à travers tikzmaker pour avoir un .tex.
Ces fichier tex sont ensuite compilés en eps et pdf puis en svg avec pdf2svg.
Ce sont toutes ces étapes qui sont automatisées avec un makefile. Cela fait maintenant plusieurs mois que j’utilise cette mécanique que je trouve très satisfaisante. On voit ici que l’approche code permet de modifier des figures extrêmement rapidement grâce à l’automatisation totale. Par ailleurs, cette approche peut permettre de versionner ses figures ; chose que je n’ai pas encore fait mais qui se mettra facilement en place si la nécessité apparaît.
Traduction
Comme je l’ai dis, cette mécanique existe chez moi depuis un moment, j’en avais déjà parlé à l’occasion de précédents billets. La partie innovante de cet article est la traduction. En effet, je dois parfois intégrer mes figures dans des articles en anglais ou dans des documents pour des congrès internationaux. A d’autres moments, ce sont des figures en français dont j’ai besoin.
Dans l’action, il y a deux possibilités : soit on modifie le fichier source en changeant toutes les chaines d’une langue à une autre, soit on duplique le code et on traduit la copie. Chacune de ses méthodes a son inconvénient. Pour la première, je risque d’osciller entre version anglaise et française au gré de mes besoins. la perte de temps est considérable car je dois refaire ce que j’avais fait. Pour la seconde méthode, je ne traduis qu’une seule fois, mais si je modifie la figure, alors je dois reporter les modifications sur mes traductions, chose qu’on ne manquera pas d’oublier et on se perdra dans les sources après quelques mois.
L’idée est d’utiliser un outil dédié à la traduction. A l’occasion de l’écriture d’un code (inforevealer) que j’ai un peu complètementabandonné par manque de temps, j’ai découvert le projet po4a qui s’appuie sur gettext pour traduire les fichiers qui ne sont pas du code (tex, ini, text…). Ce projet est codé en perl, il faudra adapter un peu le logiciel en ajoutant un module.
Le but de po4a est d’aller chercher les chaines de caractères dans nos fichiers .pgf et .plt. Les .chem n’ont, chez moi, pas de contenu à traduire. Ces chaines sont stockées dans un fichier .pot que l’on copiera en fr.po. Ce fichier fr.po est le fichier dans lequel il faudra traduire les différentes chaines.
Je crée d’abord un fichier de configuration pour po4a (ex po4a.cfg) :
[po_directory] po/
[type: Gnuplot] plot/plot.plt fr:plot/plot.fr.plt
[type: Tikz] fig/fig.pgf fr:fig/fig.fr.pgf
La première ligne nous dit que les traductions se trouveront dans le répertoire po/ (à créer). Il faudra y créer un fichier .pot (le nom n’importe pas) vide. Ensuite on lancera une première fois la commande :
po4a po4a.cfg
Puis on ajoute notre traduction fr :
cp po/master.pot po/fr.po
On traduit et on lance une nouvelle fois :
po4a po4a.cfg
Ceci fait, le fichier plot/plot.plt sera traduit en plot/plot.fr.plt et il suffira de relancer le makefile pour compiler la figure francophone. Ceci décrit donc le déroulement du processus de traduction.
Comme vous l’avez remarqué, il faut indiquer un type (ici Gnuplot et Tikz). Ces types, je les ai créé en ajoutant des bibliothèques perl dans /usr/share/perl5/vendor_perl/Locale/Po4a (chemin sur archlinux). C’est assez simple à réaliser (à condition de connaître un peu perl et les expressions rationnelles). Le fichier Ini.pm offre une bonne base pour la syntaxe. En passant, remarquez que le copyright de ce fichier (sous GPL) est attribué à BitDefender (j’aime ces petites découvertes dans les codes). Pour les fichiers gnuplot, j’ai pris le parti de mettre les chaines à traduire entre double quotes, les autres entre simple quotes. De ce fait, j’utilise pour le moment un copie du fichier Ini.pm pour Gnuplot.pm. Cependant, ce code ne permet de récupérer qu’une chaine par ligne. C’est assez peu gênant, mais j’améliorerai ça plus tard. Pour les fichiers Tikz, il suffit de récupérer le contenu des node{} au lieu des double quotes en prenant garde qu’il peut y avoir des options (node[above] {}).
Voilà pour la partie technique. Les avantages que je vois à cette méthode sont les suivantes :
Un fichier unique pour toutes mes traductions.
Pas de redondance de traduction : si “theory” apparaît 10 fois dans 10 fichiers différents, la traduction me sera demandée qu’une fois. Sachant que les figures voient apparaître des termes récurrents, c’est un gain non négligeable.
Pas de duplication de code à proprement parler. En pratique, il l’est : plot.plt et plot.fr.plt, mais on ne modifiera que plot.plt car plot.fr.plt est généré à partir de plot.plt et fr.po par po4a.
Les codes (tikzmaker, makefile…) sont tous triviaux, néanmoins s’ils intéressent quelqu’un, je peux les mettre à disposition. Pour les bibliothèques perl, elles sont en cours de test… mais j’ai déjà une bonne dizaine de figures traduites avec succès.
