Groff est l'implémentation GNU du logiciel de formatage de texte Troff. Il est majoritairement utilisé aujourd'hui pour mettre en forme les pages de manuels, mais il réunit toujours autour de lui une communauté d'utilisateurs convaincus.
Depuis longtemps déjà, Werner Lemberg, le mainteneur principal du projet ne pouvait plus y consacrer beaucoup de temps. Il a officiellement fait appel ce week-end à un nouveau chef de projet pour Groff. La suite de la dépêche détaille le contexte de cet appel à candidature.
Sommaire
Contexte de l'appel à candidature
Il y a quelques mois, Werner Lemberg, qui a longtemps maintenu Groff avec soin, annonçait aux membre de la liste de discussion de Groff que celui-ci n'était plus pour lui une priorité :
Je vais donner la priorité à d'autres travaux, particulièrement FreeType et ttfautohint. Pour l'instant, je suis particulièrement occupé à faire évoluer ces logiciels, et je serais vraiment reconnaissant si quelqu'un pouvait s'occuper de la tâche de mainteneur principal…
En annonçant cela, il ne faisait qu'officialiser une situation bien connue : le développement de Groff est fortement ralenti depuis plusieurs années. Les utilisateurs de Groff semblaient d'ailleurs s'être résignés au fait que Groff n'évoluerait plus vraiment. Seuls quelques passionnés continuent à utiliser Groff pour formater leurs textes, et même pour afficher les manuels, Groff est maintenant fortement concurrencé par mandoc. De fait, Groff n'attire plus suffisamment d'utilisateurs pour qu'il y ait parmi eux une proportion suffisante de développeurs motivés pour le maintenir.
Il a donc fallu attendre ce week-end pour que quelqu'un manifeste quelque inquiétude quant à l'avenir de Groff. Et c'est Peter Schaffter, le créateur de la macro mom, qui est aussi connu pour être un fervent défenseur de Groff, qui s'est exprimé le premier à ce propos :
Nous ne retrouverons jamais quelqu'un comme Werner, mais la tâche est devant nous : où ira Groff dorénavant, et qui prendra la barre ?
Après quelques discussions, Werner Lemberg a publié un appel à candidature sur la liste de discussion des développeurs du projet GNU :
Chers amis,
Nous avons besoin d'un nouveau mainteneur pour Gnu Troff. Quand bien même j'applique quelques modifications critiques ici où là, je n'ai plus la force de participer activement au développement du logiciel.
Sachez que Ted Harding, mon co-mainteneur, ne code pas du tout; il est plutôt cette personne bienveillante qui prend soin des demandes des utilisateurs sur la liste de discussion (et je suis vraiment reconnaissant qu'il le fasse).
Je pense que le logiciel lui-même est en très bon état; il compile sans problèmes sur la plupart (sinon toutes) les plateformes, pour autant que je sache.
Tâches du futur mainteneur
Dans ce mail, Werner Lemberg énumère rapidement les tâches qui lui semblent prioritaires.
Maintenance générale
Remplacer le repos CVS par un DVCS moderne (je préfère git).
Ceci fait suite à la proposition de Éric S. Raymond de s'occuper justement de cette tâche.
Mettre à jour l'infrastructure pour utiliser gnulib. Pour l'instant, seul un module utilise gnulib, ce qui est un gaspillage de ressource et est difficile à maintenir.
Faire en sorte que Groff utilise automake.
Une meilleure utilisation des outils Gnu par Groff n'est pas un simple effet d'annonce : à plusieurs reprises, Werner Lemberg a précisé sur la liste de discussion que la façon correcte de corriger certains problèmes supposait d'utiliser tant automake que gnulib.
Améliorations techniques
Implémenter l'algorithme de Tex de formatage des paragraphes, ou un équivalent - je considère que le formatage des paragraphes lignes après lignes pratiqué par Groff est son point faible. Voir heirloom troff comme un exemple de la façon dont cela pourrait être implémenté.
L'algorithme en question est rapidement évoqué dans l'article anglais word wrap de wikipedia et est décrit en détail dans l'article de Knuth Plass : Breaking paragraph into lines, in Software practice and experience. On pourrait aussi penser aux algorithmes de micro-typographie qui ont motivés la création de PdfTex, et qui sont aussi incorporés dans Heirloom Troff.
Adapter Groff au monde des polices d'aujourd'hui. Celles que Groff supporte nativement (Postscript type 1) sont dépassées depuis 15 ans. À nouveau, Heirloom Troff implémente cela.
La gestion des polices est douloureuse avec Groff. Les polices postscript elles-mêmes doivent être converties dans le format historique de Troff pour être utilisées avec Groff. Que Groff sache utiliser les polices OpenType par défaut semble être un minimum aujourd'hui.
Meilleur support de l'Unicode.
À vrai dire, Groff ne supporte pas l'unicode : il fait appel à un pré-processeur (preconv) qui convertit pour lui les fichiers d'entrée en ascii. C'est une solution qui fonctionne bien, mais qui a quelques défauts : certains fichiers qui ne sont lus que tardivement par la chaîne de commandes de Groff ne sont pas convertis, l'utilisateur n'ayant alors pas d'autres choix que de le faire manuellement.
Éléments de motivation
Travailler avec la communauté de Groff sur le code source de Groff peut se révéler être une belle expérience :
- Avant d'être un ensemble d'algorithmes, la typographie est un art soucieux du détail et marqué par l'histoire. L'implémentation des algorithmes typographiques est probablement autant une affaire de génie logiciel qu'une affaire de bon goût - et il y a certainement place pour l'invention. Le mainteneur de Groff aura là une belle occasion d'entraîner son œil de typographe puisque c'est essentiellement la qualité gris typographique produit par Groff qu'il s'agit d'améliorer.
- L'implémentation informatique des bonnes pratiques typographiques est un terrain de jeu de développeurs de renom. De fait, ce sont les textes et le code source de Kernighan et Knuth qu'il faudra étudier pour les adapter à Groff.
- La communauté de Groff a ceci d'étrange qu'elle réunit des défenseurs d'interfaces textes, des universitaires formés aux sciences humaines, et de vieux utilisateurs de logiciels libres, dont certains ont activement participé à son histoire. Le ton de la liste de discussion y est toujours feutré et respectueux, et il y a un certain plaisir à suivre la vie de cette communauté.
Aller plus loin
- GNU Troff (250 clics)
- Appel à candidature (81 clics)
- Maintenir un projet Gnu (37 clics)
- DLFP : Jouons avec Unicode: Tchars, un Dchars pour Troff (31 clics)
- DLFP : Utroff est publié (42 clics)
# Je suis perdu
Posté par JGO . Évalué à 10. Dernière modification le 17 novembre 2013 à 18:57.
Peux-tu situer troff, heirloom troff et groff (et utroff) dans cette histoire ?
J'ai vaguement trouvé que troff est un programme des années 70, nroff une version “new” de 1972, groff la réécriture gnu ; il semble que Heirloom troff fournit troff et nroff, et toi-même tu as créé utroff par dessus. Pourquoi une telle fragmentation de la communauté ?
[^] # Re: Je suis perdu
Posté par Sygne (site web personnel) . Évalué à 10.
La question est donc: pourquoi Gunnar Ritter a forké le Troff de Solaris plutôt qu'il n'a amélioré Groff ? Je suppose que c'est parce qu'il a été un utilisateur sinon développeur d'unix propriétaire pendant un temps, et qu'il a voulu se plonger dans le code des outils Unix.
Pour ma part, j'ai rencontré Troff via le projet Heirloom, et comme c'était un peu compliqué pour moi au début, j'ai d'abord utilisé Groff. Mais mon cœur penchait pour Heirloom Troff. J'ai vite compris que Werner Lemberg ne donnerait pas à Groff les fonctions typographiques d'Heirloom Troff, aussi, lorsque je me suis senti assez solide techniquement, j'ai fait le saut vers Heirloom Troff.
Il manque à Groff ce soin du détail en typographie, mais il a plein d'avantages sur Heirloom Troff, en particulier sa facilité d'usage, mais aussi une bien meilleure gestion des dessins et de la couleur, et le fait que tous les pré-processeurs (pic, eqn, tbl) sachent produire de l'xml. Il est aussi mieux documenté, et il a une communauté vivante et très expérimentée. Enfin, il y a fort à parier que son code source soit bien plus lisible.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.