J’utilise zim tous les jours, notamment afin de conserver ma veille. Cette veille est issue du traitement de mes flux RSS. Lorsqu’une page contient une information intéressante sur un sujet, j’ajoute le lien dans la page zim qui correspond. J’y ajoute parfois des commentaires. Je fais de même lorsque je navigue (recherche d’astuces, comparatif pour achats…). Je pense que la majorité des personnes utilisent des marques pages dans leurs navigateurs. Je ne trouve pas cela pratique car il est difficile de les ranger, de les manipuler, de les commenter. Zim m’enlève cette difficulté.

Problématique

Cependant, chacun sait que le web bouge sans cesse. Le problème vient lorsque vous décidez de vous pencher sur un sujet. Vous ouvrez la page zim en relation afin de retrouver toutes les informations accumulées aux fils des mois ou des années. Vous retrouvez vos liens mais certains sont morts. Plusieurs raisons à cela : le site peut être inaccessible, avoir changé de CMS (liens cassés), de domaine ou simplement avoir disparu, voir le contenu retiré… dommage le lien était intéressant.

Première tentative

Nous ne sommes pas les premiers à faire ce constat, d’autres ont anticipé en créant des archives du web. La plus connue est sans doute archive.org. D’ailleurs, je vous conseille le module resurrect pages pour firefox.

Il y a toujours un mais… La solution n’est pas idéale, car nous sommes dépendant d’un service qui peut ne pas avoir archivé la page souhaitée : le crawler n’est pas passé au bon moment, le crawler n’est pas parvenu jusqu’à la page ou le site n’a jamais été visité…

Seconde tentative

L’idée est de mettre en place sa propre archive. On n’est jamais mieux servi que par soi-même, pas vrai ? Les outils utilisés par ces sites d’archives me semblent démesurés pour mes besoins. Un wget de la page me suffirait amplement dans 95% des cas. Bien sûr, on ne va pas faire ça à la main, ce serait trop long, et rapidement on ne le ferait plus.

Un script python va donc nous sauver la mise. En scannant à la recherche d’url toutes nos pages zim, il va récupérer la page avec le module urllib.request. Cette page est sauvée dans l’endroit de son choix. On ajoute un lien (comme le fait wikipedia dans les références via wikiwix) vers notre fichier téléchargé. Zim gère l’ouverture des fichiers avec xdg-open, chez moi c’est géré dans

~/.local/share/applications/mimeapps.list

Un simple clic sur l’archive ouvre la page dans le navigateur.

Le script peut être automatisé à l’aide d’une tâche cron ou via la fonctionnalité “outil personnalisé” de zim.

Quelques remarques

Comme je l’ai spécifié, j’utilise urllib.request. Je n’ai pas trouvé mieux dans la récupération de page. Si vous connaissez une bibliothèque plus performantes, je suis toujours preneur.

J’ai du changer le user-agent. Pour ceux qui ne connaissent pas, c’est la façon dont est identifié le visiteur du site. Par défaut, c’est python, je l’ai changé pour Firefox car des sites comme wikipedia me jetais. Sans doute parce qu’ils préfèrent qu’on utilise l’API.

La solution est implémentée pour zim, mais l’idée est générique pour ceux qui utiliseraient d’autres solutions de prise de note.

Idées d’amélioration

Il serait peut être pertinent de rafraîchir les archives tous les mois en conservant les versions anciennes (au cas où). Typiquement, certains commentaires sont très utiles et il peut être bon de les avoir. Une autre bonne chose serait d’avoir la possibilité d’empêcher délibérément l’archivage. Parfois, j’ai des liens vers des dépôts pour lesquels il n’y a aucun intérêt à avoir une copie ! Si vous avez d’autres propositions…

Code

C’est sous GPLv3, nécessite python3. J’ai déposé le code ici, plus pour information que pour production pour le moment, le code est relativement chaud. Si des gens sont intéressés par des versions stables dans le futur, je les proposerai.

Récemment, j’ai mis en place un sélecteur de licence permettant à un contributeur d’apposer facilement une licence parmi une sélection (ou de mettre une licence ‘custom’ si aucune n’est satisfaisante). Ceci se fait très facilement en modifier la page spéciale MediaWiki:Licenses. Il suffit d’y faire une liste de modèles  et ces modèles insère le texte adéquat de la licence (ou un lien y référant). La question de la licence est bien évidemment centrale dans ce type d’outil de travail, il en va de la possibilité de diffuser et de réutiliser les productions des contributeurs.

Ceci étant fait, il s’est posé la question des fichiers ayant été envoyés par le passé pour lesquels il n’y avait pas eu de licence précisée (environ 1200 fichiers). Pour palier ce manque, j’ai écris quelques lignes de code afin de mettre à jour automatiquement ces fichiers en question.

J’avais pour point de départ un fichier csv que j’ai parsé à l’aide d’un premier code perl pour créer des fichiers dont la syntaxe est de type ini, facile à manipuler. Je produit un fichier par utilisateur concerné. Chaque entrée concernant un fichier dont la licence est à préciser.

Un courriel est envoyé à chaque personne pour demander de compléter le champ licence, puis, à la réception de celui-ci, il est lu par un deuxième script via la bibliothèque Config::IniFiles. Les informations sont ajoutées à la page mediawiki idoine, comme l’aurait fait le sélecteur de licence, via la bibliothèque WWW::Mechanize.

Le choix de perl s’est fait lorsque j’ai appris (merci VX et Tangui) que la bibliothèque perl mechanize était bien mieux documentée que la bibliothèque python (devinette inside via 3 exemples). C’est tout de même plus rassurant…

Ca se code tout seul… si on n’oublie pas les deux lignes pour se loguer à mediawiki avant (certains comprendront ). En espérant que cela serve ou donne des idées à quelqu’un.

Ces notes doivent rester privées. Pour cela, j’ai utilisé le mode mod_auth de lighttpd permettant de mettre en place un mot de passe sur le dossier. L’une des principales menaces dans la mise en place de ce type de protection est l’attaque par brute-force. Alors que lighttpd a été patché en mai 2010 pour que le log contienne l’IP lors d’un échec d’authentification, aucune règle pour fail2ban n’existait. Je l’ai donc créée.

Les modifications que j’ai apporté ont été commité dans un fork git du projet. J’ai effectué une demande de merge auprès de la communauté de fail2ban, leur laissant le soin d’améliorer si besoin est.

PS : encore une preuve de la simplicité de contribuer au logiciel libre, l’écriture du billet a été plus longue que la contribution elle-même.

Je conçois cette adoption en deux temps. La première a dû se faire à l’époque où l’accès internet s’est démocratisé avec les premières connections ADSL : Mandrake était alors une distribution reconnue pour les débutants. Cette première vague s’est suivie, selon moi, d’une seconde par ubuntu qui a réussi à provoquer un mouvement communautaire très fort, époque où la moindre sortie d’une nouvelle version mettait en branle les blogs qui s’empressaient de relayer l’information. Il y a probablement eu dans ce succès un effet certain des versions de microsoft de l’époque (vista notamment) où les utilisateurs avertis de Windows cherchaient quelque chose qui fonctionne.

Ces deux vagues ont permis d’une part d’améliorer la prise en main des logiciels libres en les rendant plus conviviaux et plus simples (pour quoi le souhaite, on peut toujours installer des distributions/logiciels réputés difficiles). La documentation et les sources d’informations se sont multipliés au point que désormais il est facile de trouver les solutions à ses problèmes ou à ses interrogations. Je trouve remarquable qu’aujourd’hui le mot “linux” ait déjà été entendu par beaucoup de personnes, ce n’était pas le cas il y a 10 ans.

La question qui peut s’imposer est alors l’existence d’une troisième salve. Doit-on s’y attendre ? Je ne le crois pas. La puissance de frappe qu’a eu ubuntu a sans doute déjà permis de sensibiliser les personnes prêtes à écouter, comprendre et essayer un monde différent : qu’il soit technique ou philosophique. Je ne parie pas d’aussi grand succès à des distributions récentes telles que Mageia qui joue sur ce créneau. Bien sûr, leur travail est utile car d’une part, il y aura toujours un flot continue de nouveaux et que l’une des qualités du logiciel libre est d’avoir autant d’alternative qu’il y a de penser la chose, la diversité en somme. Pour ces deux raisons, ce travail est nécessaire.

Au sein des utilisateurs de logiciel libre, il y a ceux qui y voient un intérêt certain dans la qualité, la stabilité, la diversité, le prix ou tout autre raison pratique. D’autres ont franchi une étape supplémentaire en adhérant à une pensée libriste, dirons-nous même si celle-ci ne doit pas être au fond unique ni totalement synthétisable. De ces deux groupes, tous font l’expérience d’une maitrise, de la maitrise de leurs systèmes, de leurs logiciels et ainsi de la maitrise de leurs données. Cette maitrise est découle de la transparence du code et de l’utilisation de format ouvert qui rendent respectivement plus confient dans la sûreté et dans la pérennité de l’information.

Si la description s’arrêtait là, elle serait douce et merveilleuse mais depuis quelques années, les internautes que nous sommes utilisons de plus en plus de services. J’appellerai ces services, services distants par opposition aux services locaux que nous rendent nos bons logiciels libres installés sur notre disque par nos soins. Ces services distants sont gérés par d’autres, sur une machine de quelqu’un d’autre et pour un grand nombre d’entre nous. Nous, utilisateurs de ces services, nous ne faisons que les utiliser en donnant nos données… rien ne nous assure qu’elles ne seront pas exploitées, combinées, réutilisées par autrui. Rien ne nous assure même que nous pourrons les récupérer un jour. Ces services ne supplanteront pas, enfin j’en suis persuadé, nos logiciels locaux, mais ils cohabiteront car les modèles sont différents et complémentaires. La cohabitation fera qu’un utilisateur ne sera plus libre, de fait.

Le défis lancé  au monde du libre est pour moi celui-là. Permettre à ces personnes qui ont compris les qualités du code libre, qui ont saisi à quel point leur liberté ne pouvait d’exercer sans, de pouvoir bénéficier de services distants maîtrisés. À preuve du contraire, la maitrise des services distants passe nécessairement par un contrôle physique de la machine et du code qui y est exécuté. En effet, des réflexions sont menées afin de conceptualiser un service libre. Cependant, cela nécessite, à un moment ou à un autre, de donner confiance aux administrateurs.

En terme plus clair cela revient à dire que le serveur doit se retrouver chez vous pour que vous restiez seul propriétaire physique des informations et le serveur doit exécuter du code libre pour maîtriser ce qu’il adviendra de vos données (comment elles sont traitées). Dans ce cas, on a ce que j’appelle des services distants-locaux.

Aujourd’hui, il y a à ma connaissance deux projets ayant pour objectif d’installer des services distants-locaux : FreedomBox et BeedBox.

Le premier a été porté par Eben Moglen alors que les révolutions du monde arabe éclataient. L’idée étant de fournir des “plugbox” dont l’installation serait enfantine et qui rendraient les libertés numériques de ses utilisateurs. Le second prend sa source avec une conférence de Benjamin Bayart (internet ou minitel 2.0) où il soulignait que les briques logiciels pour créer un serveur mais il n’y a pas la glue qui ferait un tout cohérent et facilement gérable. Beedbox a été lancé par un groupe francophone.

Ayant appris l’existence de Beedbox après celle de FreedomBox, j’ai d’abord cru en des projets identiques. En réalité, les deux projets oeuvrent sur des terrains voisins et complémentaire.

Alors que le projet FreedomBox est davantage centré sur les questions de lutte contre la censure, de vie privée et d’anonymat afin de permettre un accès libre à l’information et la liberté d’expression, Beedbox se concentre à rendre accessible l’auto-hébergement. L’objectif est clairement de permettre à quiconque le souhaitant d’héberger les services dont il a besoin afin de contrôler au mieux ses données.

Les deux projets ont en commun la défense de la neutralité du net ainsi que le contrôle des données. Ils sont à mes yeux les chrysalides du monde libre.

Liens pouvant intéresser le lecteur :

• Owncloud
• Archost
• No-Box
• Livre : Pour un web ouvert
• Beedbox
• FreedomBox

J’utilise, sans doute comme de nombreux internautes, les flux RSS (ou atom) afin de suivre des planet ou divers sites. Jusqu’ici, j’utilisais thunderbird pour les récupérer. J’ai essayé d’utiliser d’autres logiciels tels que newsbeuter sans être parvenu à les adopter. La critique que je fais à un logiciel CLI est l’absence de gestion des images, ce qui oblige d’ouvrir la page dans un navigateur pour visualiser pleinement l’article. Une opération de trop. Quant aux autres logiciels graphiques (mes derniers tests remontent à au moins deux ans), ils ne m’ont guerre séduit car ils n’apportaient rien de plus et je devais lancer un logiciel supplémentaire. Je vais revenir sur cette raison.

Quel que soit le logiciel, une de mes préoccupations provenait de la fréquence des synchronisations : que se passera-t-il si je n’allume pas fréquemment ma machine ? Réponse, je vais louper des articles. Ce n’est pas la fin du monde, mais c’est gênant.

Solutions distantes (web)

Pour palier ce problème, on peut utiliser une machine tournant 24h/24 pour récupérer les flux, ainsi plus aucun loupé. Je ne parle délibérément pas des services proposés par certaines entreprises car je considère que mes flux sont des données importantes de ma vie privée.

Ayant un petit serveur, je peux héberger moi-même un service qui fait la même chose. Une approche bien connue est celle de tinytinyRSS ou encore RSSlounge : ces logiciels possèdent une interface web.

Pourtant séduisante, cette possibilité ne me convient pas. J’aime avoir mes flux dans mon courrielleur. Apprenti GTG que je suis, les conseils de Frédéric Couchet me font dire que je dois réduire au maximum le nombre d’entrée (sources de tâches). Devoir d’une part traiter mes courriels avec un logiciel puis voir ailleurs pour traiter mes flux va à l’encontre de ce conseil.

Solutions distantes (courriel)

L’idée est donc d’envoyer les articles comme des courriels. Il existe quelques solutions. Artisan-linux a préféré utiliser un logiciel qui injecte directement dans une boite imap. Pour ma part, j’ai choisi un logiciel qui envoie sur une boite mail… que j’utilise en imap (pour les avantages que tout le monde verra). Ce logiciel est rss2email. Je déconseille le paquet debian, très patché (trop ou pas assez à mon goût…), le principal soucis est qu’il n’utilise pas d’extraheader RSS-feed qui me permet de filtrer pour organiser mes flux. Le logiciel fonctionne bien. Même si la récupération et le traitement des flux est bon, la gestion des IO me semble très mauvaise : je préfère de loin un fichier de configuration éditable à la main. Le petit inconvénient est que je dois gérer la classement dans thunderbird, ce n’est pas le logiciel qui le fait (au contraire de la solution d’artisan-linux je crois). Ceci dit, je ne me connecterai avec un autre client que dans de très rares occasions (2 fois par an maxi), ça ne me semble pas gênant.

Ainsi, j’obtiens mes infos directement dans mon courrielleur, j’ai réduit mon nombre de répertoire (toujours via à vis de GTD) en remplaçant un répertoire par flux par un répertoire par thématique.

La boite que j’utilise est une boite Imap de chez gandi (à défaut d’une boite sur mon serveur pour le moment). L’espace étant limité (enfin, pas tant que ça), cela va me motiver à garder ces dossiers vides. Je prends un flux et je le traite : pas d’accumulation

D’un point de vue vie privée et auto-hébergement, ce n’est pas optimal, mais déjà pas mal.

• Synchronisation de N clients sur un serveur
• Accès hors ligne des données (et modification), synchro à la prochaine connexion
• Automatisation des synchro (dès qu’il y a quelque chose à synchroniser et que la connexion existe, on y va)
• Utilisation en ligne de commande possible (et GUI pour qui veut)
• En bonus, historique des fichiers

Revue

Cette revue est sans doute incomplète mais elle est le résultat tout de même de nombreuses heures (par dizaines) à fouiner un peu partout et à tester. J’espère qu’elle sera utile à celles et ceux qui se posent la même question et peut être à éclaircir (en vue de développements futurs ?) les points forts et faibles de l’existant. Je parle ici uniquement des solutions libres pour lesquelles les données peuvent être mises sur un serveur maitrisé par l’utilisateur final (auto-hébergement…). J’avoue ne pas avoir tout testé. Aux personnes qui pensent dropbox, je les renvoie là et là.

Rsync

Unison

Un vieux software performant. C’est le rsync bidirectionnel. Il peut être utilisé en local ou à travers du SSH et peut être automatisé (option batch). Le seul hic est qu’il n’a pas le moyen de vérifier qu’une nouvelle synchro est nécessaire, autrement dit, ce n’est pas un démon. Il faut le coupler à autre chose comme inotify. Inotify permet d’envoyer des signaux lorsqu’il y a des modifications sur le système de fichier (création, accès, destruction…)

Unison étant pour moi une des solutions les plus à même de répondre aux besoins, je ferai un paragraphe dédié en fin d’article (bidouilles possibles). Cependant, elle ne l’est pas en l’état. Certains ont essayé de faire des adaptations avec le logiciel suivant.

Lsyncd

Lsyncd est conçu pour palier l’absence d’inotify dans rsync. Le projet semble avoir déjà une petite maturité. Le problème est qu’avec rsync, on tombe à nouveau dans une solution unidirectionnelle. Une solution utilisant Unison à la place de rsync semble prometteuse. L’idée est de synchroniser via ssh en utilisant le puissance de unison lorsque le système de fichier est changé (lsyncd). L’auteur procède même à du reverse ssh afin de déclencher une synchronisation dû à un changement de l’autre coté (je peux presque m’éviter ça… j’y reviendrai). En lisant les commentaires, on remarque qu’une personne a remonté un problème : les tâches unison sont lancées en série. L’écueil est que la synchronisation démarre sur un fichier spécifique mais que la synchro est globale. On voit vite qu’on peut créer un grand nombre de processus unison parce que plein de petits fichiers son modifiés successivement. On a vu mieux.  Le hack n’est pas parfait.

SSHfs/webdav

Je n’ai pas essayé sshfs mais webdav via owncloud. J’imagine que le premier souffre des mêmes critiques que le second qui sont que le travail hors ligne est impossible. Je n’ai trouvé aucune solution logicielle permettant de travailler sur du webdav hors ligne. Attention aussi à la moindre déconnexion internet. Si vous continuer à utiliser votre logiciel parce que vous ne faites pas attention et qu’il accède aux données, les surprises vont arriver rapidement (j’ai testé…).

Le hack que je vois ici est :

1. de monter le webdav si connexion active
2. synchroniser avec la copie locale
3. démonter

Sparkleshare

Certains ont crié victoire à l’arrivé de ce logiciel (tout au moins dans le titre ). Le problème est qu’à l’heure actuelle, le projet est jeune et que le client est en mono. Je ne suis pas emballé pour l’instant par ce logiciel, mais bien plus par l’idée. Concept concurrent à Unison, Sparkleshare utilise la puissance de gestionnaires de version tel que Git. C’est pour moi la condition sine qua none d’une bonne qualité : reposer sur un système éprouvé. Ce système est avant tout utile pour des fichiers non binaires, en effet, les performances chuteront dès qu’il s’agira de renvoyer le fichier en intégralité. Mon avis est que c’est un faux problème, car je ne cherche pas à synchroniser Zim comme des photos. Pour des photos, j’utiliserais bien plus webdav qu’une solution de synchronisation comme sparkleshare.

Git permet d’avoir l’historique, un bon point mais certains disent que le dépôt risque de prendre du poids rapidement. Git permet de modifier l’histoire, je ne suis pas un gourou mais je pense qu’en se penchant dans la doc, on doit pouvoir trouver le moyen d’alléger le dépôt régulièrement.

dvcs-autosync

Passons maintenant à celui-ci. Ce logiciel utilise Git, inotify et Jabber (XMPP). Le substitut à sparkleshare par excellence. J’ai été un peu surpris de l’utilisation de jabber, celui-ci sert visiblement à communiquer entre les divers instances. C’est pour moi la révélation de cette revue, simple, efficace, mes pré-tests sont tout à fait concluant. Ce logiciel est une perle qui devrait être bien plus largement connue. Une discussion a eu lieu sur le forum d’archlinux.

Syncany

Voici un logiciel en java. Il semble très prometteur aussi puisqu’il a pour ambition d’être chiffré et peu dépendant du support de stockage : FTP, IMAP, Webdav, SSH et bien d’autres… La version que j’ai testé ne fonctionnait pas (FTP ou webdav ou SSH, commit initial impossible). Difficile de donner un avis, mais la première version n’est pas encore sortie. C’est pour moi un logiciel à surveiller de très près. Il faudra voir la robustesse en gestion de conflits etc.

Lipsync

Suite à cet article, j’ai aussi trouvé ce logiciel que je n’ai pas réussi à faire fonctionner. J’ai commencé à modifier le code pour résoudre divers bugs et puis j’ai rapidement lâché. La qualité n’est pas à la hauteur de mes espérances. D’après ce que j’ai vu, il n’utilise que rsync… (?)

Csync

Je mentionne aussi l’existence de ce projet csync qui semble mort. Pas testé de ce fait.

Rubydrop

Rubydrop est un projet plus à l’échelle du projet personnel. La dernière activité remonte à décembre 2010 et la licence est exotique. Par manque de conviction, je n’ai pas testé non plus.

Conclusion de la revue

De nombreuses solutions et très peu qui fonctionnent out of the box pour moi. Il y a deux concepts qui sortent du lot : le bon vieux Unison et des gestionnaires de version comme Git. L’utilisation de inotify est selon moi un atout, mais limite l’interopérabilité avec les systèmes windows notamment (comme ça ne m’importe pas…). Les autres systèmes de type webdav ne répondent pas à nos besoins, ils sont par contre bien plus utiles pour des dépôts de documents, photos, vidéos, sons… Là où une synchronisation manuelle à un sens (on ne synchronise pas des photos tous les quatre matins). Pour les données d’un logiciel utilisé au quotidien, c’est inadapté.

Parmis les solutions à surveiller, je dirais :

• Syncany
• Sparkleshare (principalement la recherche d’amélioration concernant mono)
• dvcs-autosync : peu connu et qui mériterait de l’être plus. Actuellement, c’est la seule solution viable à mes yeux.

Addendum : Bidouilles possibles

Si on s’ennuie, on peut envisager des petites bidouilles (hacks). Ce sont de petites pensées, le coeur de l’article n’est pas là

Webdav

Je vois assez bien un hack très rapide avec webdav. Comme expliqué plus haut, ne pas travailler directement dans le répertoire monté, mais synchroniser dedans avec unison. Synchroniser par cron me semble peut intelligent. Par contre, incron devrait être facile à utiliser (ou un script perl/python avec une lib inotify).

Unison

A l’image de lsyncd + unison, je pense qu’on peut écrire un petit code (perl ou python par ex) avec la lib inotify qui lancerait des synchro avec unison. J’éviterai l’erreur ci-dessus en groupant les synchros. Autrement dit, je ne lance pas une synchro dès qu’il y a un signal lancé par inotify. Je limite par ex la fréquence des synchro et j’attends toujours que la précédente soit finie pour lancer la nouvelle. C’est l’absence de cette deuxième condition qui selon moi pose problème.

J’ai parfois des soucis avec le reverse ssh (erreur du type  ssh_exchange_identification: Connection closed by remote host) objets de longues discussions sans solution sur les forums alors que je suis déjà parvenu à le faire fonctionner. Néanmoins, je pense que synchroniser au démarrage de la machine et après des temps d’inactivité long suffirait (à titre personnel). En effet, je ne travaille que sur une machine à la fois et un long moment se passe lorsque je change de machine (temps de trajet d’au moins 10 minutes). On devrait dans ce cas pouvoir se passer d’une communication serveur vers clients.

Plusieurs raisons m’ont poussé à installer un serveur chez moi :

• Apprendre (parce que mine de rien, ce n’est pas trivial)
• Synchroniser des fichiers en maîtrisant mes données
• Avoir la possibilité de monter quelques pages web
• Echanger quelques fichiers via ftp
• Récupérer mes flux RSS. Thunderbird montre ses limites quand il s’agit d’être déconnecté un bout de temps.
• Et pour toutes les fois où il est utile d’avoir une machine distante
• Ainsi que ce que je n’ai pas encore pensé

Configuration

Vous pouvez télécharger et diffuser (c’est sous licence libre !) aussi les autres affiches (éducation, appel à la libération des oeuvres) dans vos écoles, associations…

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 :

1. Chemfig pour les formules chimiques (.chem)
2. Tikz pour les schémas (.pgf)
3. 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.

• Qualité Latex
• Langage déjà connu
• Format interopérable (pdf)
• Facilité de l’intégration de mathématiques (l’écriture est lisible, le résultat de qualité) : indispensable pour moi
• Customisation possible avec Tikz (même si je l’utilise assez peu au final pour mes slides)

Cependant, latex beamer a un inconvénient, c’est celui de son format lorsqu’on veut avoir des  choses un peu plus exotiques (animation, video…). Bien sûr, intégrer une vidéo dans un pdf est possible mais ça reste de la bidouille, de l’arnaque. Qui plus est, une technique pourra très bien fonctionner avec un lecteur (au hasard adobe acroread) mais pas avec un autre (evince, okular…). Cette situation ne me satisfait donc que partiellement.

Html/CSS

L’idée est d’utiliser du html afin de produire notre présentation (je préviens de suite que je suis très loin d’ếtre éclairé à ce sujet). J’ai déjà assisté à des conférences où une telle technologie était utilisée (ubuntu party…) et c’est Loïc Dachary qui m’a poussé à me repencher au problème. Une solution toute faite existe : DZslides. La licence de ce modèle est très permissive : WTF Public License. Autrement dit, on pourra mettre les présentations sous n’importe quelle licence. L’écriture des transparents ne déroutera pas le latex beamer-ophile. Dans un grand fichier, il suffit d’écrire les pages les unes à la suite des autres dans des balises

<section>
blabla
</section>

Les règles classiques de l’html s’appliquent alors. Une fois la page ouverte dans le navigateur, on se déplace avec les flèches du clavier ou avec une télécommande… classique.

On pensera à changer ce bout de code (ligne commentée + ma nouvelle ligne)

<!– <link href=’http://fonts.googleapis.com/css?family=Oswald’ rel=’stylesheet’> –>
<link href=’oswald-style.css’ rel=’stylesheet’>

dans le cas où on ne dispose pas de connexion internet lors de la présentation. Le fichier oswald-style.css contient la contenu de l’url, tout simplement.

Intégration de vidéo

L’intégration d’une vidéo se fait sans encombre grâce à l’html5 :

<video width=”400″ height=”222″ controls=”controls” preload>
<source src=”video.ogv” type=”video/ogg” />
</video>

Ceci devrait suffire.

Intégration des graphiques et images générés par Latex

Ceux qui me suivent un peu savent que j’utilise latex à la fois pour les figures (tikz ou chemfig) et pour les graphiques (gnuplot avec le sortie tikz). Des petits codes et des makefiles me permettent de sortir directement à partir des sources, les fichiers utilisables : pdf, eps (lorsque je dois échanger avec des gens utilisant latex et non pdflatex) et un tex avec la bibliothèque standalone.

Pour intégrer nos images, il va falloir un autre format. Je travaille avec latex tout du long de ma chaine de production de contenu afin d’ssurer une bonne qualité. Ainsi, je vais continuer en ce sens en produisant un fichier vectoriel svg. J’utilise pour cela l’utilitaire pdf2svg empaqueté chez debian et archlinux (et sans doute ailleurs).

Pour insérer dans la page, on utilise la balise embed.

Et les maths dans tous ça ?

Il faut maintenant réussir à écrire des mathématiques. Passer par un fichier contenant la formule est une technique fréquemment utilisée par les gens utilisant des logiciels comme Libreoffice. Ceci ne me satisfait par car il me faudrait ajouter une étape lors de ma production, la génération de l’image à partir du code Latex. On (François, tu te reconnaîtra) m’a parlé de mathml : c’est un langage xml permettant d’avoir un rendu d’équation. Très bien, mais ajouter à la main des portions de code mathml ne rend pas la solution meilleure à mes yeux et mathml est trop abscons pour que je le tape directement. Il existe des “convertisseurs” latex-mathml, mais on retombe sur le point pénalisant précédent. En poursuivant mes recherches sur cette piste, j’ai rouvé mathjax, un code javascript publié sous licence Apache v2 (les sponsors et partenaires sont de qualité : AMS, Elsevier, APS…).

Après avoir récupéré les fichiers, il suffit de mettre par ex dans le header :

<script type=”text/javascript” src=”mathjax/MathJax.js?config=TeX-AMS_HTML”></script>

Divers configurations existent… Je vous renvoie à la doc qui est très très bien faite, il y a même des démos en vidéo. Le texte doit se trouver dans des balises <p> </p> :

<p>
\begin{align}
\dot{x} & = \sigma(y-x) \\
\dot{y} & = \rho x – y – xz \\
\dot{z} & = -\beta z + xy
\end{align}
</p>

On peut utiliser les $ aussi. J’ai pour l’instant un problème avec les $ simples, mais aucun avec $$. Je remplace mes $ simples par \( et \).

Voilà, je pense qu’avec ces divers éléments, la production d’une présentation de qualité et alternative à Latex beamer est possible. Pas encore testé, mais pour remplacer dzslides, on pourra se tourner vers le projet html5rocks pour les slides, le code peut être récupéré avec un wget ou directement sur le dépôt mecurial du projet. Il présente quelques fonctionnalités sympathiques comme l’intégration de notes, le zoom, le changement de thème…