Génération de slides avec Beamer, dia, minted

Tout est fragile

La première astuce est de toujours déclarer les frame en fragile (une frame est un slide). L'option fragile indique à LaTeX de faire très attention, et permet l'inclusion de graphique, de colorisation syntaxique, ... à l'intérieur du slide. Sans cette option, LaTeX risque d'exploser à la compilation dés qu'on sort un peu de l'ordinaire.

Par exemple un slide sera déclaré ainsi

\begin{frame}[fragile]
\frametitle{Gestion de la lexemisation}

\end{frame}

Une page par section

En LaTeX on défini le plan (et donc, la table des matières) du document avec des commandes du type \section et \subsection. Par défaut, Beamer ne génère pas de page de garde lorsqu'on change de section. Il est possible de le faire en définissant une nouvelle commande du type :

\newcommand{\newsection}[1]{\section{#1}

\begin{frame}
  \frametitle{#1}
  \begin{center}
    {\Huge #1}
  \end{center}
\end{frame}
}

Et en utilisant ensuite \newsection au lieu de \section pour changer de section.

Une table des matières en colonnes

En utilisant l'extension multicol il est très simple d'avoir la table des matières (ou n'importe quelle autre slide) sur deux colonnes (ou plus).

Le code ressemble à :

\begin{multicols}{2}
\tableofcontents
\end{multicols}

Principes du Makefile

Pour ceux qui ont déjà fait du C (ou autres langages compilés), le concept des Makefiles ne vous ait sans doute pas étranger. Mais les Makefiles peuvent s'utiliser dans bien d'autres cas.

Le concept d'un Makefile est d'expliquer à la commande make comment fabriquer (to make, en anglais) des fichiers à partir d'autres fichiers.

Un Makefile se compose de règles. Chaque règle contient trois éléments :

1. Le nom de la règle (qui peut être le nom d'un fichier à générer, ou nom virtuel) ;
2. La liste des dépendances nécessaires pour fabriquer cette règle ;
3. Les commandes à exécuter, une fois les dépendances satisfaites, pour fabriquer cette règle.

Un exemple de Makefile

Par exemple, on commence par définir une règle all (qui par convention fabrique tout ce dont on a besoin en temps normal) définie ainsi :

all: slideshow.pdf article.pdf

Cette règle ne contient aucune commande, mais indique qu'il faut fabriquer les deux fichiers slideshow.pdf et article.pdf lorsqu'on invoque la commande make  all. Ou juste make car cette règle est la première du fichier (make sans argument fabrique la première règle qu'il trouve).

Ensuite, on explique à make comment fabriquer ces deux fichiers, avec des règles du type :

slideshow.pdf: slideshow.tex common.tex $(wildcard src/*.tex)
      $(PDFLATEX) slideshow.tex && $(PDFLATEX) slideshow.tex

article.pdf: article.tex common.tex $(wildcard src/*.tex)
      $(PDFLATEX) article.tex && $(PDFLATEX) article.tex

Ces règles indiquent à make que les fichiers .pdf dépendent de certains fichiers .tex (celui du même nom, le common.tex qui contient des définitions générales, et tous les .tex du répertoire src). Ces fichiers sont notre source, que nous éditons avec notre éditeur de texte préféré (GNU Emacs par exemple). Elles indiquent aussi comment fabriquer le PDF, en exécutant deux fois pdflatex sur le fichier source principal. Pourquoi deux fois ? LaTeX a besoin d'être lancé deux fois, sinon la table des matières peut ne pas être à jour.

La gestion des dépendances

À quoi servent donc ces dépendances ? À indiquer à make ce qui doit être reconstruit quand on a fait une modification. Par exemple, si je modifie le fichier slideshow.tex alors make saura qu'il doit reconstruire slideshow.pdf mais pas article.pdf. Si je modifie common.tex il saura qu'il faut reconstruire les deux.

Format vectoriel, pas bitmap

Dia est un logiciel de diagrammes faisant partie du projet Gnome. Il fonctionne en vectoriel, et sait exporter dans des formats bitmaps (comme le png) ou vectoriels (comme le svg).

On peut donc tout simplement exporter le dia en bitmap, puis l'inclure dans le PDF avec l'un des commandes d'inclusion de bitmap de LaTeX. Mais si on procède ainsi, on part d'un format vectoriel, on le converti en bitmap, pour l'inclure dans un format ... vectoriel. Cette double conversion se fait au prix d'une taille de fichier plus élevée, et surtout, d'une baisse de qualité, en particulier si on souhaite zoomer sur le PDF généré.

Il est donc préférable d'utiliser un export vectoriel de dia. Dia propose beaucoup de formats de sortie, dont même du LaTeX directement. Mais ces formats mettent un certain nombre de contraintes sur le fichier LaTeX dans lesquels ils sont inclus.

Il existe un format vectoriel conçu directement pour l'inclusion dans un autre document : il s'agit de l'encapsulated postscript (ou EPS), que dia sait générer.

On peut directement inclure cet EPS dans le LaTeX, si on souhaite, au final, obtenir du PostScript. Si on souhaite obtenir du PDF (pour être plus amical avec les possesseurs de systèmes où les lecteurs de PostScript ne sont pas installés par défaut), il faut d'abord convertir le EPS en PDF, via la commande ps2pdf.

Inclusion dans les slides

Ensuite, pour inclure le schéma dans les slides, il suffit d'un simple :

\includegraphics{monfichier}

On peut spécifier la taille (largeur ou hauteur) que l'on souhaite avec du :

\includegraphics[width=7cm]{monfichier}
\includegraphics[height=5cm]{monfichier}

Et on peut lui demander de center si on veut, par exemple :

\begin{center}
  \includegraphics[width=7cm]{src/heuristic}
\end{center}

Intégration au Makefile

L'étape suivante consiste à éviter d'avoir à exporter le diagramme avec dia, puis à convertir l'EPS en PDF. Nous avons un outil capable de générer un fichier à partir d'un autre : make.

Ajoutons donc deux règles au Makefile :

%.pdf: %.eps
      ps2pdf -dEPSCrop $< $@

%.eps: %.dia
      dia -e $@ -t eps $<

La première explique à make comment générer un PDF à partir d'un EPS, et la deuxième un EPS à partir d'un fichier DIA. Ainsi, dés qu'on modifie notre fichier avec dia, make fera tout seul les deux étapes de la conversion en PDF.

Il reste uniquement à indiquer à make quels sont les graphiques à générer, ce qu'on peut faire en définissant une variable GRAPHICS :

GRAPHICS=src/v2.pdf src/v1.pdf src/old.pdf src/heuristic.pdf

Et en précisant que nos fichiers PDF finaux dépendent de ces graphiques :

slideshow.pdf: slideshow.tex common.tex $(wildcard src/*.tex) $(GRAPHICS)

Et le tour est joué. Je sauvegarde mon heuristic.dia, je relance make, et il regénérera tout ce qu'il faut.

Problématique

Il existe de multiples manières d'intégrer du code source dans LaTeX. L'environnement verbatim de base, des extensions comme listing, ...

L'idée ici est non seulement d'avoir du code source dans LaTeX, mais aussi d'avoir de la colorisation syntaxique.

Prérequis de minted

Minted est une extension LaTeX, disponible sur https://code.google.com/p/minted/ . Elle s'appuie sur Pygments une bibliothèque (et des programmes l'utilisant) en Python qui gère la colorisation syntaxique d'un grand nombre de langages.

Minted nécessite aussi le package color fournit de base dans la plupart des distributions LaTeX.

Utilisation

Une fois minter installé, pour l'utiliser il y a trois étapes :

1. Ajouter un \usepackage{minted}.
2. Configurer le thème de couleur à utilise avec un \usemintedstyle{tango} (voir l'aide du programme pygmentize pour plus d'informations).
3. Mettre le code dans un environnement minted, avec le langage à utiliser en paramètre (voir l'aide du programme pygmentize pour la liste des langages supportés, il y en a vraiment beaucoup).

Par exemple :

\begin{minted}{python}
ids = request.user.relation_set.filter(user_type="friends").only('id')
results = longquery(Q(user_id__in = ids)&
                    Q(text__containswords = request.GET['search'] ))
\end{minted}