Journal Redécouverte : Roff

Posté par  . Licence CC By‑SA.
Étiquettes :
67
19
jan.
2022

Sommaire

Bonjour tout le monde !

Je me suis récemment intéressé à comment produire des documents PDF avec roff et ses différents outils (groff, pic, eqn, tbl, refer…). J'apprécie l'outil et le résultat, donc je voulais partager ça avec vous.
(Il y a même du bonus à la fin.)

Comme la dépêche la plus complète sur Roff a été postée il y a quasiment dix ans, je suppose que de nombreux utilisateurs actuels du site ne connaissent pas cet outil, ou très peu. Je vais donc en toucher quelques mots, sans entrer dans les détails.

Avant de commencer : je suis plutôt novice, et au-delà de quelques démonstrations, ce texte est le reflet de mon parcours avec l'outil.

Qu'est-ce que roff ?

Roff est à la fois un langage et des « compilateurs » de ce langage. Des ensembles de macros existent pour rendre l'écriture plus agréable (et ajouter de la sémantique). Certaines macros sont spécialisées pour produire de la documentation de commandes et de code, d'autres pour écrire des romans, d'autres des documentations techniques, une thèse, des présentations, etc.

Bien que sa conception remonte au début des années 70, Roff est toujours d'actualité. Différentes implémentations sont disponibles, comme groff, ou des implémentations spécialisées, comme mandoc pour la création de pages de manuel. Il est également utilisé pour la création de RFC !

Divers formats sont possibles, les plus courants sont les formats pdf et tty (pour des pages de manuel en ligne de commande), mais le html est aussi possible, ou encore le simple texte.

NB : dans la suite je parle indistinctement de roff et troff pour désigner le langage. En ligne, vous trouverez les deux appellations.

Modèle commenté

Se mettre à roff n'est pas trivial. La documentation pour un débutant est pas terrible, ce qui est quand même super dommage (et un peu ironique). L'outil mériterait pourtant d'être plus connu ! Donc rien de mieux qu'un modèle, fortement commenté, pour montrer l'exemple :

Ce modèle a pour objectif de présenter les différents outils disponibles avec roff; le modèle est une démonstration de ce qu'on est facilement en mesure d'obtenir. J'ai fait ce document parce que c'est ce que j'aurais aimé avoir à mes débuts.

Autre exemple (complet) de document :

.TL       \" titre du document
Exemple de document
.AU       \" auteur
Karchnu
.AB       \" début de l'abstract
Ceci est un exemple de document écrit avec roff.
.AE       \" fin de l'abstract
.NH       \" titre de section
Titre
.PP       \" paragraphe indenté
Paragraphe.
.PS       \" début de dessin avec "pic"
box
line
circle
.PE       \" fin de dessin avec "pic"

Le résultat ressemble à ceci : Exemple de document roff avec macros ms
Comme on peut voir, il n'y a que peu de code. Roff est un format pensé pour être écrit par des humains, il n'y a donc que très peu de superflu.

La voie d'UNIX

Les outils autour de roff (groff, tbl, eqn, pic, grap, etc.) ont plein de qualités.

Ligne par ligne

La conception des outils est simple : tout repose sur la lecture ligne par ligne des sources.
De fait, les outils sont simples à comprendre et à étendre.

Une tâche, un outil

Voici un exemple de compilation d'un document roff :

soelim < sources.roff | eqn | tbl | pic | grap | refer | groff -Tpdf > document.pdf

Chaque outil gère un aspect du document :

  • soelim = interprète les requêtes ".so" (toutes les sources en un seul flux, un « include » si vous préférez)
  • eqn = équations
  • tbl = tableaux
  • pic = schémas
  • grap = graphes
  • refer = références bibliographiques
  • groff = compilateur de roff

Chacun de ces outils prend en entrée le texte source de tout le document et produit du roff.

Un outil, une langue

Un document roff n'est pas écrit qu'en roff. Presque chaque outil a sa propre langue, permettant de décrire précisément l'intention de l'auteur.

Le meilleur exemple de ça est pour moi pic. Voici l'exemple donné précédemment :

box
line
circle

Ici il n'est plus question d'écrire du roff à la main, mais d'avoir un langage dédié à l'élaboration de schémas. Cela permet de décrire le rendu souhaité, sans distraction.

Il est également possible de créer des fonctions pour factoriser au mieux le code. Du roff peut être inclus pour éviter de réécrire des fonctionnalités qui existent déjà (comme la gestion des polices par exemple). L'ensemble forme un tout cohérent.

Faire des schémas comme ceux-ci est simple :
Exemple de schéma avec pic : lentille gravitationnelle
Exemple de schéma avec pic : diffraction circulaire
De plus, la description de ces schémas se rapproche de la programmation, et tout peut être paramétré. Il serait donc possible de modifier les tailles des différents composants de ces images de manière dynamique, via de simples variables.

Modularité

Les outils sont indépendants les uns des autres et peuvent être remplacés à tout moment. Si on a une nouvelle implémentation trop géniale de tbl, son remplacement dans la chaîne de compilation est trivial.

Simplicité

roff est largement moins complexe que LaTeX. Pas besoin de plusieurs giga d'espace disque pour générer un PDF avec deux paragraphes; seuls quelques binaires minuscules sont nécessaires.

Autre métrique pour juger de la complexité de l'application : le temps de compilation est instantané, y compris sur de très vieilles machines et de gros documents.

Cette rapidité a un effet de bord plutôt appréciable; il est possible d'avoir un rendu généré à chaque modification des fichiers. C'est ce que j'utilise pour avoir un retour immédiat de ce que j'écris grâce à entr. D'ailleurs, si vous utilisez le makefile de mon dépôt, vous pouvez juste taper make serve et vous aurez par défaut votre document généré dans /tmp, et regénéré à chaque modification.

Sémantique

Roff permet d'étendre le langage en créant des macros. Par exemple, je me suis fait une macro "SECTION" pour ajouter de nouveaux titres numérotés :

  .SECTION Nouveau chapitre
  Coucou ceci est le début du chapitre.

Les macros permettent de changer facilement le style du document, tout en ajoutant de la sémantique.

Les différentes commandes (pic, grap, etc.) possèdent également des macros (ou fonctions). Cela permet de faire du code réutilisable et configurable.

Faire ses propres outils

Créer de nouveaux outils pour roff est assez simple, il faut juste faire un programme qui prend en entrée les sources du document et renvoie des commandes roff.

Compilation d'un document avec un nouvel outil révolutionnaire :

  eqn < source.roff | nouvel-outil | groff -Tpdf > document.pdf

Par exemple, j'ai ajouté de la coloration syntaxique avec ghighlight (préprocesseur roff, qui fait appel à source-highlight). Dans les sources de mes documents, ça donne :

  .SOURCE C
  int main (void) {
    return 0;
  }
  .SOURCE

Et voilà, on a du C coloré dans le document final.

NB : j'ai également vu dans un ancien article linuxfr qu'il existait d'autres outils pour mettre de la coloration syntaxique dans troff. Notamment, vgrind qui servait autrefois à ajouter de la couleur à du code dans le terminal, et qui peut se coupler avec ugrind pour en faire un préprocesseur Roff. Je verrai plus tard si vgrind pourrait remplacer avantageusement ma solution, il semble couvrir moins de langages et ma solution fonctionne, donc bidouiller vgrind n'est pas dans mes priorités là tout de suite.

Un logiciel qui a 50 ans

Je ne vais pas revenir sur toute l'histoire derrière Troff. D'autres l'ont fait avant moi et mieux que je ne saurais le faire. En revanche, le fait que ce langage soit si vieux est important à mentionner, à plusieurs égards.

  1. Le langage est robuste dans le temps; il ne semble pas avoir beaucoup changé au fil des décennies.
  2. La compilation d'un document roff est quasi instantanée, la complexité du langage étant adaptée aux machines des années 70.
  3. Il existe plusieurs implémentations des mêmes outils, souvent faites à différentes époques. Cela peut engendrer des confusions.
  4. La documentation autour du langage et de ses outils est inégale.
    • Certains outils ont une documentation exceptionnellement bonne, à l'instar de pic, ou de Roff lui-même qui a une documentation toujours valide (et excellente) depuis 1978. Le site troff.org aide beaucoup à se documenter.
    • En revanche, tout n'est pas simple, et la documentation des requêtes (commandes Roff) peut laisser à désirer. Notamment dans la documentation de Groff, la seule implémentation que j'ai utilisée jusque-là.
    • Les pages de manuel sont souvent incomplètes ou pas à jour, mais ça s'améliore.
  5. Malgré son âge et les nombreuses implémentations abandonnées, certaines implémentations sont toujours bien actives. Par exemple, Groff reçoit encore régulièrement de nombreux commits, et mandoc a été présenté en 2015 puis en 2018 comme étant une implémentation dédiée à la création de pages de manuel (spécifiquement pour l'ensemble de macros mdoc). OpenBSD a officiellement adopté mandoc pour sa documentation.

Roff a 50 ans, et a encore de beaux jours devant lui.

Par ailleurs, je conseille la lecture de For the love of troff qui explique pourquoi on ne se débarrassera pas d'un outil comme troff facilement.

NB : de ce que j'ai compris, un jour groff a été devancé par TeX sur quelques points. Par exemple la gestion de l'alignement du texte sur les lignes, qui se faisait ligne-par-ligne au lieu de prendre en compte tout le paragraphe. De même, les équations étaient mieux gérées sur LaTeX. Mais le développement se déroulant à bon train, il ne me semble pas que ces critiques soient toujours d'actualité. Si vous en savez plus, n'hésitez pas à vous manifester dans les commentaires !

Limitations

Je ne prétends pas être un expert. Je suis un simple utilisateur qui a fait un petit bout de chemin avec ces outils et uniquement avec les macros ms. Parfois, ce chemin s'est transformé en parcours du combattant, voici quelques raisons :

  1. L'inclusion d'images. C'est possible et je l'ai fait dans mon modèle présenté plus haut, mais les tailles des images sont mal gérées. J'ai un peu bidouillé pour que ça tombe en marche (2 lignes, rien de bien méchant). Par ailleurs, le format PS ou PDF semble imposé pour les images.
  2. Les références intra-document. Faire référence à une section ou un chapitre par exemple.
    1. La bibliographie est correctement gérée avec refer, mais l'outil ne gère pas les références vers des sections d'un document.
    2. Les macros ms ne semblent pas comporter de macros pour gérer automatiquement des références. Il existe une macro pour créer un sommaire, mais c'est à peu près tout.
    3. Il est possible d'écrire explicitement une référence. Le problème est qu'il faut gérer la numérotation des pages dans les références à la main.
    4. Il est possible de faire soit-même des macros gérant les références intra-document, c'est juste dommage que ce ne soit pas de base, surtout pour les débutants.
    5. J'ai peut-être manqué l'outil qui fait ça et que tout le monde utilise depuis toujours, comme le dernier des boulets. À défaut de trouver une meilleure solution, j'ajouterai des macros pour gérer ça dans mon modèle.
  3. L'inclusion de nouvelles polices. C'est faisable, mais pas simple.
    1. C'est simplifié en utilisant le script install-fonts.sh (un peu de documentation à ce propos).
    2. Pas de ligatures avec le script présenté au point précédent. J'ai ajouté la police FiraCode et les ligatures ne sont pas présentes. Je n'ai pas suffisamment de connaissances à ce sujet pour savoir ce qui ne va pas.
    3. Le format accepté des fichiers de polices est le TrueType Font (du moins, c'est le format qui peut être facilement converti dans le format accepté par groff), et je ne crois pas qu'il y ait beaucoup d'autres formats disponibles.
    4. neatroff rend facile l'ajout de polices, mais je n'ai pas encore joué avec cette implémentation.
  4. Des notions contre-intuitives. La gestion des environnements, par exemple, réserve quelques surprises.
  5. L'intégration de liens PDF.
    • Il faut activer de nouvelles macros (les macros ms n'incluent pas la gestion de liens PDF).
    • Là encore, c'est géré de base dans neatroff.
  6. Rendu navigateur moche. Je ne sais pas quelle est la cause, mais le texte de base est hideux.

En bref, rien d'insurmontable.
Ces problèmes peuvent probablement se résoudre en contactant une communauté d'utilisateurs. Je pense également que l'usage des macros ms y est pour quelque-chose, ces macros sont parmi les plus simples mais offrent moins de possibilités.

Dans les problèmes rencontrés mais réglés :

  1. UTF-8. Il faut appeler preconv dans la chaîne de compilation ou faire appel à groff -k. J'ai eu des problèmes (je ne me souviens plus des détails) qui m'ont mené à implémenter un filtre remplaçant les caractères UTF-8 (principalement des accents) en leurs macros ms respectives. Comme pour preconv, il suffit de mettre mon script dans le pipeline de compilation et l'UTF8 est géré.
  2. La confusion entre les implémentations, les macros et où trouver de la documentation. Les pages de manuel sont parfois incohérentes entre elles, ou incomplètes, voire peu claires. Ça prend un peu de temps pour être à l'aise, et même si je n'ai pas encore appris tous les concepts, ça rentre petit à petit.
  3. Sous OpenBSD, le fichier de configuration troffrc présent par défaut empêche catégoriquement de justifier les paragraphes. C'est pour cela que le dépôt du modèle inclut un troffrc personnalisé. Rien de bien méchant, mais c'était frustrant à mes débuts.

En tout cas, avoir un exemple comme le modèle que je vous ai partagé m'aurait grandement aidé.

Pourquoi je m'y suis intéressé (optionnel, je raconte ma vie)

Avant de terminer, un petit mot sur la raison qui m'a poussé à me renseigner sur Roff, au cas où ça intéresse quelqu'un.

Mes débuts avec la typographie

J'ai passé une thèse en 2019 en informatique. Cette expérience m'a obligé à bouffer de la création de documents à n'en plus finir (ma thèse a été 6 mois de développement, le reste c'est de l'écriture de papiers). J'aimais pas ça, mais petit à petit j'y ai pris goût. Écrire un papier, c'est voir son idée grandir, se développer, se préciser, et obtenir un meilleur rendu (pour satisfaire un journal qui récolte tout le fruit de ton travail sans un merci parce que t'es complètement sa p…).

En tout cas, voir son papier gagner en maturité, voir le rendu s'améliorer sous les ordres conseils de son directeur de thèse, c'était assez plaisant.

Lire et retenir

Aujourd'hui, comme je n'ai pas eu le temps de le faire pendant mes études, je me documente sur plein de sujets qui m'intéressent. Par exemple, j'ai commencé à regarder des langages de programmation qui ont des paradigmes que je n'ai pas suffisamment explorés. Un peu d'astronomie, de politique aussi.

Plus je bouquine, plus j'ai envie de résumer ce que je lis. Documenter pour ne pas oublier. Je ne suis pas un grand lecteur, et relire un livre m'est rébarbatif : je lis pour apprendre, pas pour le plaisir de lire.

Documenter, mais quel format ?

Le format web :
Résumer un livre via un article de blog n'est pas un format qui me convient. Le web est selon moi un foutoir incroyable, le html incluant de force une sémantique (pauvre) et se basant sur des outils trop compliqués. Tout change, tout le temps : les outils, les langages, les sites web. Je ne parle même pas des centaines de technos existantes et bâclées. Un site ça vit, ça meurt. Je veux sortir de cette logique.

Le format papier :
Un document PS ou PDF s'approche du format papier, et selon moi les papiers de recherche ont le meilleur format pour résumer et expliquer des concepts. Comme le web, un document papier comporte des titres, tableaux, schémas, couleurs, graphes, équations et un style facilement modifiable. Mais le format papier possède également des notes en bas de page pour ce qui relève du détail anecdotique. C'est un format connu, universel et agréable. Autre avantage : pouvoir collecter ces documents sans l'intermédiaire du web (nos navigateurs sont des monstres), apprécier une lecture hors ligne. Tout ça c'est important pour moi.

Documenter, mais quel outil ?

Pour ma thèse, j'ai utilisé LaTeX, comme tout le monde. J'aime plutôt bien cet outil, mais je voulais en expérimenter d'autres, plus minimalistes. LaTeX a quelques gros avantages par rapport à sa concurrence (LibreOffice et MS Word), mais il reste plutôt gourmand (taille, durée de compilation) et complexe. Idem pour les outils qui gravitent autour. Au fond, ai-je besoin de quelque-chose d'aussi lourd pour mes documents perso ?

Je veux un format papier et typographier sémantiquement mon document (par exemple, lorsque je cite un module ou une fonction). Au revoir markdown.

Roff a piqué ma curiosité de part son âge et son adoption (plus ou moins) universelle sur les distributions Linux et les BSD. Après tout, pourquoi vouloir installer d'autres outils que ceux qui sont déjà présents, s'ils font le travail ? Puis je suis l'élite de la nation au RSA, j'ai le temps de me documenter sur des langages obscurs.

Mes débuts avec roff (bonus !)

Après avoir dissipé légèrement ma confusion entre tous les outils existants (implémentations, macros, les outils annexes), et surtout après avoir vu une page montrant des exemples qui m'a bien motivé à pratiquer, j'ai fait quelques tests sur ma machine.

Par la suite j'ai résumé ce que je lisais avec groff. Je n'ai terminé aucun de mes documents pour le moment, j'ai un peu la bougeotte. J'ai quand même bien entamé certains sujets, quelques exemples de résumés :

  • Haskell pour explorer la programmation fonctionnelle. Gros morceau que je tente d'expliquer à ma façon (sans trop de jargon mathématique). J'ai expliqué les bases et j'ajoute des parties de temps en temps. Mon objectif étant de résumer tout ce que j'ai pu lire sur le net à ce sujet; marre de fouiller des centaines de commentaires reddit pour avoir une explication cohérente. Une fois que le document sera suffisamment avancé j'en ferai peut-être une dépêche sur linuxfr (abonne-toi, mets la cloche).
  • « A Universe From Nothing » de Lawrence Krauss. Je m'intéresse aussi à l'astronomie, et j'ai commencé à résumer le livre. Je suis loin d'avoir fini de résumer (seuls les 2 premiers chapitres sont réellement là), mais ça peut donner une idée d'un rendu.

J'ai également quelques notes par ailleurs, pas assez avancées pour être montrées pour le moment. Notamment mon point de vue sur les langages de programmation en général (petite explication du comment et du pourquoi de Haskell, LISP, tcl, Zig, assembleur, m4, dc, awk, etc.).

NB : le style de ces documents n'est pas définitif. Je mets peut-être un peu trop de couleurs et la police pourrait être changée par endroits. Mais cela donne de bons exemples de ce qui est possible avec troff.

Conclusion

Parfois j'ai l'impression que les outils disponibles pour troff sont en avance par rapport aux outils modernes. Par exemple, pic est un outil de programmation pour générer un schéma, avec tout la souplesse que ça apporte. Faire des schémas avec une GUI me semble, dans une certaine mesure, plus contraignant. C'est d'autant plus le cas quand on doit faire plusieurs schémas pour un même document, forcer le même style pour tous les schémas est trivial avec pic (mêmes polices, épaisseur de traits, etc.).

Malgré avoir utilisé LaTeX pendant des années, j'ai davantage lu la documentation de groff et je pense mieux le maîtriser.

Les documents produits sont d'une qualité suffisante à mon goût. Je vois encore des modifications à apporter à mes macros et je continue de jouer avec l'outil, mais j'ai suffisamment de recul pour comprendre que roff me convient.

Bref, j'attends vos retours ou vos questions si vous en avez. Merci de m'avoir lu jusqu'ici !

PS: si vous éprouvez une haine viscérale envers Roff et consorts, passez votre chemin. J'ai aucun problème avec ça, mais ne perdons pas notre temps dans des dialogues de sourds.

PS : si Sygne est toujours parmi nous, je veux bien savoir si son projet utroff est toujours pertinent. Il en avait fait des dépêches il y a maintenant 8 ans, et le site est malheureusement hors ligne maintenant.

  • # roff'er \o/

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Merci beaucoup pour ce journal qui tombe bien : je me disais ce week-end que je pourrais publier certains cours que j'avais donné sur le sujet ici (en attendant de monter mon site pour les y publier aussi.) Je ne suis pas expert non plus, mais j'ai pas mal utilisé et apprécie ces outils.
    Merci aussi pour les références : je n'avais pas vu les traitements fait ici, et découvre Sygne grâce à ce journal.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # vs

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    roff est largement moins complexe que LaTeX. Pas besoin de plusieurs giga d'espace disque pour générer un PDF avec deux paragraphes; seuls quelques binaires minuscules sont nécessaires.

    Attention, on peut avoir de quoi faire du TeX qui tient sur une disquette… Comme pour faire du ROff, c'est plusieurs outils pas tous obligatoires. Pour faire simple pour les usagers de LaTeX, on a fait des suites (comme en bureautique) comme TeXLive. Ces suites viennent avec tous les programmes possibles (comparativement, sur une installation GNU/Linux de base, on n'a pas tous les utilitaires de l'écosystème ROff qui sont installés, mais juste un sous-ensemble utilisé pour les pages de man…) ainsi que les différentes polices (ça par contre ça prend de la place, et en plus à l'installation les divers cache? sont générés pour les tailles standards) et un nombre important d'extensions (du moins pour TeX Live, tandis que MiKTeX les télécharge à la demande)

    Autre métrique pour juger de la complexité de l'application : le temps de compilation est instantané, y compris sur de très vieilles machines et de gros documents.

    TeX a des algorithmes plus complexes, notamment pour la justification (comme tu l'as mentionné), et avec une précision de calcul interne qui est de l'ordre quantique si je peux dire. Mais quand tu recompiles le même document sans avoir viré les fichiers auxiliaires c'est quasi instantané. Je crois surtout que par conception les principaux auteurs essayent de ne pas utiliser trop de ressources matériel même s'il faut prendre plus de temps (dans ces années là c'était supposé tourner en batch…) tout en étant paradoxalement des programmes interactifs aussi (des sortes de shell)

    Ceci dit, je suis bien d'accord que la suite roff est plus légère.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: vs

      Posté par  . Évalué à 3.

      Merci pour tes précisions.

      Et oui, la suite roff est plus légère. La totalité des outils roff ainsi que les fichiers de configuration et les fonts représentent même pas 15 Mo sur ma machine. Même en admettant que je ne compte pas tout, soyons fous, doublons ce chiffre pour être sûr, on arrive à 30 Mo. Avec LaTeX on arrive rapidement à plus d'un giga voire deux. Et là, j'utilise groff qui est probablement la plus grosse implémentation, et j'ai installé des fonts personnalisées. La différence est colossale.

      Après, bien entendu LaTeX fait plus de choses, mais faut en avoir l'usage.

      Je veux bien considérer Tex, seul, comme étant un outil pouvant rivaliser avec roff. Pour l'instant je n'ai pas joué avec donc je n'ai pas d'avis tranché sur la question. D'un autre côté, en connaissant roff et en étant satisfait des résultats produits, j'ai du mal à voir l'utilité derrière Tex. Je suppose que les références intra-document sont gérées de base, puisqu'il n'y a pas de gestion de document ligne-par-ligne, mais c'est un peu du détail, àmha.

      Dans un tout autre style, j'aimerais bien regarder SILE. Ici le gros avantage est de gérer très finement (et simplement) du texte avec des placements qui sortent de l'ordinaire. Je pense que c'est un très bon outil pour faire des pages de magazines par exemple. En tout cas, je suis curieux.

      • [^] # Re: vs

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        La totalité des outils roff ainsi que les fichiers de configuration et les fonts représentent même pas 15 Mo sur ma machine. Même en admettant que je ne compte pas tout, soyons fous, doublons ce chiffre pour être sûr, on arrive à 30 Mo. Avec LaTeX on arrive rapidement à plus d'un giga voire deux. Et là, j'utilise groff qui est probablement la plus grosse implémentation, et j'ai installé des fonts personnalisées. La différence est colossale.

        Je ne pensais pas aux fontes personnalisées mais plutôt à la variété de fontes de bases (historiquement, je ne me souviens pas que Troff distinguait des équivalents de Roman et Serif) avec toutes leurs variations (par exemple le penché/incliné, qui est souvent calculé, n'est pas l'italique) et métriques. Les fichiers de base en eux même ne sont pas très gros. Une fois qu'on a besoin d'une fonte donnée, elle est générée, référencée (pour ne pas refaire la régénération lors des appels suivants) et occupe plus de place (bitmap historiquement) Pour accélérer le temps de traitement des documents et partant du principe que quand on l'installe c'est pour un usage complet et courant/régulier, les suites font toute la précompilation des combinaisons standards (les plus courantes ?) Les dernières implémentations de Troff utilisent plus de polices qui sont déjà intégrées dans le système (donc c'est souvent masqué) alors que *TeX a un format qui lui est propre (ceci dit il y a des extensions à LaTeX et une intégration native dans ConTeXt pour utiliser les TrueType du système en plus.)

        L'autre aspect ce sont vraiment les extensions. Quasiment tout ce qui a une licence non fermée ni propriétaire et est publié sur CTAN est inclus dans TeXLive.
        Pour faire le parallèle, tu as étendu selon tes besoins (colorations syntaxique.) Si Troff avait évolué de la même façon (avec une large communauté et un lieu de recensement de ces ajouts), il y en aurait un paquet et ton installation serait plus conséquente si la suite te les met toutes à disposition.

        À cela il faut ajouter la compatibilité ascendante et les travaux dérivés qui font qu'on jette peu de chose. Donc forcément tu vas avoir ta suite qui va grossir avec le temps mais te garantir une forme de pérennité (par exemple TeXLive propose LuaLaTeX et ConTeXt mais on a toujours LaTeX dans toutes ses formes et même PlainTeX et donc on arrive toujours à garder sa chaîne de traitement historique… par exemple, la présence de pdflatex ne casse pas ton Makefile qui fait systématiquement latex puis dvi2pdf)
        S'il fallait faire la même chose ici, tu devrais pouvoir lancer aussi bien l'implémentation de Groff qui améliore certaines choses mais laisse en plan d'autres, que l'implémentation historique…

        Après, bien entendu LaTeX fait plus de choses, mais faut en avoir l'usage.

        Comme ça existe déjà, j'utilise une des classes disponibles pour faire mes CV, courriers, présentations. Autant de choses pour lesquelles il me faudrait écrire moi-même les macros et convertisseurs associés si je devais utiliser Troff. (plus le temps passe et moins j'aime faire d'effort, surtout que je finis par découvrir que j'ai réinventé un truc existant.)

        Je veux bien considérer Tex, seul, comme étant un outil pouvant rivaliser avec roff.

        Oui, les deux univers adressent un certain nombre de problématiques communes et n'ont pas évolué de la même façon. Du fait de ce dernier point, on ne peut pas facilement comparer (module à module) les suites mais au mieux leur noyau (TeX et Troff)
        Après, il est toujours bien d'avoir des approches différentes et complémentaires.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: vs

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Je viens de tomber sur une nouvelle discussion (hier) sur reddit : Des usagers de l'époque 1980/1990 confirment que leur installation était assez petite…
        https://www.reddit.com/r/LaTeX/comments/sdc54k/how_was_latex_like_in_the_80s_and_90s/

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: vs

          Posté par  . Évalué à 2.

          Oui, et ils confirment que le problème vient du code qui est affreusement lourd. À l'époque ils arrivaient aux mêmes temps de compilation qu'aujourd'hui car il y avait vraiment beaucoup moins de code à lire et interpréter.

          J'apprécie quand un langage est expressif, qu'il permet d'exprimer des choses simplement, en abstrayant les détails techniques. Mais là, je pense sincèrement que l'architecture de roff est meilleure. Qu'on ne puisse pas gérer le traitement d'un bout de texte en moins d'une minute sur nos machines qui exécutent des milliards d'instructions à la seconde, c'est ridicule. Des giga de données pour savoir cracher un PDF, c'est ridicule tout pareil.

          Ce qui ne veut pas dire que roff est parfait. Parmi les trucs à améliorer, je pense à :

          1. la gestion des calculs. La gestion des nombres est un peu foireuse à mon avis, trop exotique.
          2. quelques constructions de code qui ne sont pas intuitives.
          3. la volonté d'économiser du temps d'écriture pour les auteurs est peut-être trop présente.
          4. l'écriture des macros, qui pourrait être revue. À mon avis, baser les macros sur le langage TCL serait plutôt agréable à lire, écrire. Les macros seraient peut-être très légèrement plus longues, mais tellement plus lisibles. Et en plus ce serait accessible à plus de monde, car beaucoup plus intuitif et moins exotique.

          J'ai même noté quelques citations drôles dans la documentation de groff hier.

          […] it is better not to use this feature to avoid confusion.

          (dans la doc sur les séquences d'échappement)

          Don’t use this command! […]

          (dans la doc des requête de dessin)

          Despite of being silly, […]

          (également dans la doc des requêtes de dessin)

  • # Star-TeX

    Posté par  . Évalué à 3.

    moi j'ai découvert troff (enfin, je m'y suis intéressé plus avant) quand j'ai appris que "le" bouquin de programmation en Go (Kernighan & Donovan) avait été écrit avec troff.

    ça m'avait bluffé.

    quant à la lourdeur de LaTeX vs troff, oui, certes, mais ce n'est pas une comparaison complètement valide.
    il vaudrait mieux comparer troff à tex.

    il y a un an maintenant, je me suis embarqué dans l'écriture d'une engine pour (La)TeX en Go (principalement pour ajouter le support des équations à une bibliothèque de plots en Go):

    et j'ai appris beaucoup de choses sur comment TeX fonctionne, ainsi que sa légèreté par rapport à LaTeX.
    par exemple, star-tex (qui ne supporte que les documents "tex", pas "LaTeX") est extrêmement léger et rapide.

    • [^] # Re: Star-TeX

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      moi j'ai découvert troff (enfin, je m'y suis intéressé plus avant) quand j'ai appris que "le" bouquin de programmation en Go (Kernighan & Donovan) avait été écrit avec troff.

      En soit, ce n'est pas étonnant… la recette pour Go (K&D) est celle de C (K&R) ; et puis pourquoi s'embêter avec des trucs plus compliqués et incomplets quand on a fait du Troff tout au long de sa carrière ?
      En effet, les pilliers (B. Kernighan, D. Ritchie, K. Thompson, R. Pike, etc.) ont mis en place des choses qu'ils utilisaient vraiment (on doit à Ken l'éditeur Ed et à Brian le système Troff, tous deux étant des améliorations de programmes qu'ils avaient déjà écrits et utilisés pré-Unix…)

      et j'ai appris beaucoup de choses sur comment TeX fonctionne, ainsi que sa légèreté par rapport à LaTeX.

      Oui, on oublie souvent que LaTeX est un ensemble de macros extensibles (via le mécanisme \usepackage dans les classes) et hautement configurables (en tout cas beaucoup beaucoup plus que PlainTeX) Tous reposent sur TeX (le langage assez bas niveau avec quelques facilités de haut niveau incluses) qui est le kernel si je peux dire.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Pourquoi écarté si vite markdown ?

    Posté par  . Évalué à 2.

    Merci pour le journal !
    J’ai un peu la réponse à ma question mais il me semble tout de même que Mardown bénéficie maintenant d’un écosystème d’éditeurs puissants permettant de réaliser de belle chose grâce à l’intégration avec pandoc (notamment)… Zettlr par ex. S’il s’agit d’organiser ta documentation personnelle en markdown ou org, logseq est en train de devenir excellent.

    • [^] # Re: Pourquoi écarté si vite markdown ?

      Posté par  . Évalué à 6.

      Comme je l'ai dit dans le journal : sémantique et typographie.

      Avec markdown, on oublie toute sémantique. C'est pourtant un point crucial pour moi. Rien que pour ça, c'est éliminatoire.

      De plus, je veux pouvoir contrôler la typographie de mon document. Et je parle d'un document au format PDF, pas html, que je veux en double colonnes, en précisant moi-même les polices et leurs tailles, la taille du pied de page, etc.

      Et je suis contre l'usage d'un éditeur spécialisé. Ce sont des gadgets, lourds et inutiles, tout ce que je fuis. Mon éditeur c'est vis, point. Après avoir écrit (ou trouvé sur le net) quelques macros, on peut retrouver la simplicité d'écriture recherchée par markdown tout en ayant un environnement correct pour écrire de longs documents.

      Je trouve markdown très bien pour un mail ou un commentaire sur le net, pas pour des documents sérieux.

      • [^] # Re: Pourquoi écarter si vite markdown ?

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 06 février 2022 à 11:01.

        Je crois aussi qu'il ne faut pas écarter Markdown aussi vite.

        Dans l'enseignement secondaire, les carnets Jupyter ont le vent en poupe, en NSI c'est Python qui est enseigné principalement, et souvent avec des carnets ou alors des sites créés avec MkDocs.

        OUI, la version papier n'est pas de toute beauté ; mais qui imprime désormais ?

        Avec pandoc, on peut facilement partir du Markdown pour ensuite travailler sur un LaTeX qui sera parfait, lui, pour une version papier.

        Pour une version HTML, pour être productif avec un écosystème Python, je n'ai pas trouvé mieux que MkDocs. Voici des exemples pédagogiques :

        Et un autre bien plus matheux :

        Certains élèves impriment parfois quelques pages, c'est largement assez propre. Le jour où mon travail sera digne d'être publié, un passage par pandoc puis relecture en LaTeX, et hop.

        Pour le travail collaboratif, Markdown a déjà pris une grande longueur d'avance.

        Alors oui, il y a quelques défauts, j'en connais, c'est surtout un manque d'uniformisation des différentes versions…

        • [^] # Re: Pourquoi écarter si vite markdown ?

          Posté par  . Évalué à 7. Dernière modification le 20 janvier 2022 à 13:46.

          J'ai bien précisé mon objectif, pourquoi j'écartais Markdown (sémantique et typographie) et LaTeX (trop lourd) ou encore le HTML (documents éphémères, technos trop changeantes, etc.). J'ai précisé à chaque fois que ce sont mes goûts et mes choix pour mon objectif personnel.

          Et à cela, tu viens me dire qu'il ne faut pas écarter Markdown car on peut en faire du HTML grâce à Python et générer du PDF avec le combo pandoc et LaTeX, et que c'est pratique pour du travail collaboratif.

          Oui, avec plein de contraintes différentes, très bien, markdown c'est super. Mais pour moi c'est hors sujet. Là je parle vraiment de mes documents.

          • [^] # Re: Pourquoi écarter si vite markdown ?

            Posté par  . Évalué à 1.

            Je comprends tes contraintes (durable/PDF)… et avec les mêmes beaucoup de doctorants, chercheurs travaillent aujourd’hui avec Markdown… Rmarkdown notamment.

            • [^] # Re: Pourquoi écarter si vite markdown ?

              Posté par  . Évalué à 1.

              Si on ne prend que la contrainte de sortir un PDF, markdown, comme toutes les autres technos, ça passe.

              Différentes contraintes, différents choix. Logique.

              Si vous voulez utiliser markdown dans vos projets, faites vous plaisir. Vous avez peut-être de bonnes raisons de le faire. Dans mon cas, avec mes contraintes, markdown ne passe pas. Je crache pas dessus pour autant.

              Devinez quoi ? Il y a des gens qui écrivent des papiers voire leur thèse avec Word. Peu importe. Ça ne répond pas à mes critères.

              • [^] # Re: Pourquoi écarter si vite markdown ?

                Posté par  (Mastodon) . Évalué à 5.

                Markdown n'est pas forcément meilleur que les autres technos mais il a l'avantage d'être connu par n'importe quelle personne ayant utilisé les forges de gestion de code git, et bien supporté par une tonne d'éditeurs y compris wysiwyg.

                Ce qui est dommage c'est qu'il y a des implémentations différentes pour pallier au manque du markdown vanilla et il n'y a pas de standard pour tout ce qui concerne les diagrammes. Certains vont utiliser plantuml, d'autres flowcharts, etc.

                • [^] # Re: Pourquoi écarter si vite markdown ?

                  Posté par  . Évalué à 10.

                  Même avec des implémentations non vanilla, il ne fait pas ce que je peux faire avec troff (ne serait-ce que pour la gestion sémantique de la typographie, rien que ça il le fait pas). Si j'ai écarté markdown, c'est pas pour rien. Le fait que ce soit utilisé massivement par ailleurs me fait une belle jambe si je peux pas faire ce que je veux faire avec.

                  Et ça c'est sans compter que la complexité qu'il n'y a pas dans la syntaxe du document source se paie par ailleurs. Notamment en invoquant LaTeX pour la gestion des équations, l'usage de plein d'outils sans intégration au document pour faire des graphes et autres schémas, mais aussi la gestion bibliographique… là où tout est parfaitement intégré et tellement simple en roff.

                  Les développeurs de roff ont réussi en 1970 là où en 2022 on échoue. C'est sans appel (et un peu triste, on va pas se le cacher).

                  Markdown pour mon usage, c'est moins bien. Et je pense qu'une partie des utilisateurs de markdown l'utilisent à défaut de connaître des alternatives, mais ça c'est une histoire pour une autre fois.

        • [^] # Re: Pourquoi écarter si vite markdown ?

          Posté par  (site web personnel) . Évalué à 1.

          Il doit manquer le // voire le https:// au début de ces liens, en corrigeant :
          - https://ens-fr.gitlab.io/algo0/
          - https://ens-fr.gitlab.io/algo1/
          - https://ens-fr.gitlab.io/algo2/
          - https://ens-fr.gitlab.io/enumeration/

    • [^] # Re: Pourquoi écarté si vite markdown ?

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Pourquoi ce titre qui présuppose que cela a juste été « écarté si vite » alors qu'il n'en est probablement rien ? Pourquoi toujours partir bille en tête que si l'autre n'a pas validé le truc que nous utilisons c'est qu'il n'a pas daigné jeté un œil sinon c'est pas possible ? Il n'est pourtant pas dit dans ce journal que ton format chéri est à mettre à la poubelle, mais juste que ça ne correspond pas à son cahier des charges et son workflow. Pourquoi est-ce si dur à accepter ?

      bénéficie maintenant d’un écosystème d’éditeurs puissants […]

      En général, c'est là qu'on me voit partir en moonwalker

      S’il s’agit d’organiser ta documentation personnelle en markdown

      Voilà : pour de la petite doc (des notes, des fiches, pas de gros chapitres d'un livre) et surtout personnelle (et sans recherche d'une pérennité certaine…)

      logseq est en train de devenir excellent.

      Voilà : encore un autre outil dans lequel il faut s'enfermer à cause des limitations du format. Et cet outil essaye, à sa façon, de copier ce qui se fait dans le format wiki pour pallier les manques du format. Mais on en revient toujours au fait que le format n'est pas portable et ne permet pas grand chose sans les variations incompatibles qu'ajoutent chaque nouvelle outil ou plateforme.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Pourquoi écarté si vite markdown ?

        Posté par  . Évalué à 4.

        Ha, si seulement je pouvais like 10 fois ton message…

        • [^] # Re: Pourquoi écarté si vite markdown ?

          Posté par  . Évalué à 1.

          Évidemment vous faîtes comme vous voulez. Je ne voulais m’attirer les foudres…

          • [^] # Re: Pourquoi écarté si vite markdown ?

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            C'est moi qui m'excuse si j'ai donné cette impression foudroyante.

            Dans mon message, je voulais d'abord faire remarquer que le titre n'était pas approprié et que la question semblait orientée (on ne semblait pas être dans la curiosité de savoir les écueils trouvés dans son usage mais plutôt de la remise en cause de ce non choix, et les autres commentaires ont un peu enfoncé le clou dans ce sens.) C'est un peu dommage puisque comme tu dis, on est libre de faire comme on veut :-) Sans compter que le journal a en plus précisé les polémiques qui l'intéressait (raison pour laquelle je me suis permis le fil sur l'approche de Knut et suivants alors que je déteste les gens qui la ramènent avec LaTeX en essayant aussi de l'imposer…) et dit n'être pas intéressé par celui de MD…

            Le second point de mon message est que malgré sa "grande adoption", il ne faut pas perdre de vue sa cible (beaucoup de projets ayant besoin de documentation plus conséquente/complexe que le ReadMe utilisent RestructuredText sur ReadTheDoc ou autre plateforme Sphinx similaire, et d'autres vont mettre en place un wiki) et ses limitations (je pointe cela à travers tes exemples, mais PsychoFox reformule bien et clairement dans sons second paragraphe aussi) peuvent être des atouts ou des freins si on a d'autres prérequis. Nous avons la chance qu'il existe plusieurs solutions/approche et il continue de s'en créer c'est dire.

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # «Faire des schémas comme ceux-ci est simple»

    Posté par  . Évalué à 8.

    Ça aurait été bien que le code des deux schémas non basique soit intégré au journal, afin de voir si c'est vraiment si simple.

    • [^] # Re: «Faire des schémas comme ceux-ci est simple»

      Posté par  . Évalué à 9. Dernière modification le 20 janvier 2022 à 12:38.

      Je ne voulais pas que l'article soit un tutoriel, ça aurait été trop lourd et plutôt loin de mon objectif.

      Voici le code, commenté pour l'occasion, de la lentille gravitationnelle.

      .\" vs = vertical space (l'espace entre les lignes)
.\" ps = point size (la taille du texte)
.vs 9p
.ps 7
reset

.\" direction du dessin : quand on bouge, on descend
down

.\" ajuste la taille du dessin
scale = 1.4


.\""""""""""""""""""""""""""""""""""""""""""
.\" variables pour ajuster certains éléments

.\" distances x et y des objets agrandis à l'objet massif
mag_obj_x = 1.4
mag_obj_y = -1

.\" rayons des objets célestes
rad_obs         = 0.3
rad_massive_obj = 0.5
rad_mag         = 0.4
rad_dist        = 0.27

.\" distance du rayon de lumière de l'objet distant au centre de l'objet massif
dist_beam_massive_obj = 0.32


.\""""""""""""""""""""""""""""""""""""""""""""""""""
.\" dessin des objets célestes (planètes, galaxies…)

.\" observateur, objet massif et objet distant
OBSERVER:    circle radius rad_obs "Observer"
move
MASSIVE_OBJ: circle radius rad_massive_obj "Massive" "object"
move
TARGET:      circle radius rad_dist "Distant" "object"

.\" Nous pouvons abréger "radius" en "rad", ce que je ferais dans la suite. ;)

.\" illusions perçues par l'observateur
MAGNIFIED1: circle rad rad_mag "Magnified" "distant" "object" at MASSIVE_OBJ + ( mag_obj_x, mag_obj_y)
MAGNIFIED2: circle rad rad_mag "Magnified" "distant" "object" at MASSIVE_OBJ + (-mag_obj_x, mag_obj_y)

.\" lignes, des objets agrandis vers l'observateur
.\" chop = les lignes dessinées s'arrêtent en bordure des cercles,
.\"        elles ne vont pas jusqu'au centre

line from MAGNIFIED1 to OBSERVER chop rad_mag chop rad_obs dashed
line from MAGNIFIED2 to OBSERVER chop rad_mag chop rad_obs dashed

.\" flèches, de l'objet distant à l'observateur
.\" Note : .e = east, .w = west.
spline -> from TARGET to MASSIVE_OBJ.e + (dist_beam_massive_obj,0)  to OBSERVER chop rad_dist chop rad_obs
spline -> from TARGET to MASSIVE_OBJ.w + (-dist_beam_massive_obj,0) to OBSERVER chop rad_dist chop rad_obs

.\" (rappel) ps = point size. Ici on agrandit la taille de la police.
.ps 14
"Gravitational lensing" at TARGET + (0,-0.7)

      • [^] # Re: «Faire des schémas comme ceux-ci est simple»

        Posté par  . Évalué à 5.

        Et pour ceux qui se demandent, voici la diffraction circulaire.

        .\" Radius for different circles.
rad_large_circle = 0.6
rad_empty_space  = 0.5
rad_light_source = 0.3
rad_aperture     = 0.1

.\" Light intensity.
fill_large_circle = 0.1   # Very bright.
fill_empty_space  = 0.6   # Little bright.
fill_light_source = 0     # Completely bright.

arrow_x_shift = 0.05
txt_y_shift = 0.25   # Allow space for text.

.\" Circles.
HALO:     circle                   rad rad_large_circle  fill fill_large_circle
EMPTY:    circle with .c at HALO.c rad rad_empty_space   fill fill_empty_space 
SOURCE:   circle with .c at HALO.c rad rad_light_source  fill fill_light_source
APERTURE: circle with .c at HALO.c rad rad_aperture fill fill_light_source dashed

.\" Legend.
TAPERTURE: "Aperture, where light can pass through" ljust at HALO.e + (0.3, 0)
TSOURCE:  "Main visible light source, very bright"  ljust at Here + (0, -txt_y_shift)
TEMPTY:   "Empty space, very little light"          ljust at Here + (0, -txt_y_shift)
THALO:    "Halo, thin light"                        ljust at Here + (0, -txt_y_shift)

.\" Arrows.
arrow from TAPERTURE + (-arrow_x_shift,0) to APERTURE chop 0 chop rad_aperture
arrow from TSOURCE   + (-arrow_x_shift,0) to SOURCE   chop 0 chop rad_light_source
arrow from TEMPTY    + (-arrow_x_shift,0) to EMPTY    chop 0 chop rad_empty_space
arrow from THALO     + (-arrow_x_shift,0) to HALO     chop 0 chop rad_large_circle


.\" Let's cheat a little: centering the figure.
false_line_x = 2.7
line from SOURCE + (false_line_x,0) to SOURCE + (false_line_x,0)

.ps 14
"Circular diffraction" at HALO.s + (1, -1)

        Là encore, on peut voir qu'un objet de l'image correspond à une ligne. Il y a quelques exceptions à cela, comme les variables (des distances par exemple) ou des requêtes troff pour changer ce qui n'est pas relatif à pic spécifiquement (comme la taille des polices avec .ps 14), mais c'est parfaitement raisonnable.

        Au final on se retrouve avec des images de bonne qualité en quelques lignes, entièrement générées par troff. Pas besoin de programme externe.

    • [^] # Re: format/langage PIC

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Ou un lien pour approfondir… Il y a la/le doc/manuel, par Eric S. Raymond, de l'implémentation GNU qui est : complète, bien illustrée et intéressante. Moi j'ai appris avec le rapport original, par Brian W. Kernighan, de l'implémentation BWK : didactique et clairement illustré aussi. Ces documents sont normalement (à vérifier) disponibles quelque part avec l'installation complète de Groff.
      Voici un exemple simple tiré de la page 11 du papier de Kernighan :

      ellipse
ellipse ht .2 wid .3 with .se at 1st ellipse.nw
ellipse ht .2 wid .3 with .sw at 1st ellipse.ne

      C'est complété ainsi à la page 12 pour avoir le Mickey complet : 

      A: ellipse
   ellipse ht .2 wid .3 with .se at 1st ellipse.nw
   ellipse ht .2 wid .3 with .sw at 1st ellipse.ne
   circle rad .05 at 0.5 <A.nw,A.c>
   circle rad .05 at 0.5 <A.ne,A.c>
   arc from 0.25 <A.w,A.e> to 0.75 <A.w,A.e>

      Un bon compagnon est l'outil GNU pic2plot qui sert de visualiseur sous X (bof, la suite habituelle le fait aussi) et de convertisseur vers : HP-GL, PCL, PNG, PNM (PBM/PGM/PPM), WebCGM.
      Dans le même esprit, il y a l'outil de Dwight Aplevich, DPIC, qui fait la conversion/export en TeX (y compris LaTeX/TikZ-pgf/mfpic/PSTricks/MetaPost), PDF, SVG, PS, xfig 3.2, eepicemu.

      Comme le langage est vraiment bon, simple (autant que DOT) et puissant (autant que MetaPost), D. Richard Hipp (cf. SQLite et Fossil) l'a dérivé (i.e. certains trucs en moins et d'autres augmentés) pour donner naissance à Pikchr dont anaseto a parlé sur dfpl avec un exemple qui ne fonctionne avec l'outil traditionnel sans adaptations.

      Nota: coller les exemples sur https://pikchr.org/home/pikchrshow pour visualiser en ligne.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: format/langage PIC

        Posté par  . Évalué à 2.

        pic et les outils que tu présentes sont de pures beautés. Je ne comprends pas comment on peut se farcir des outils comme LibreOffice Draw pour faire des schémas qui peuvent se faire en quelques lignes avec pic.

        À la limite, de nos jours, pic pourrait être amélioré pour intégrer des images, par exemple. Je vois éventuellement quelques améliorations possibles comme ça, mais la base est tellement solide ! C'est une telle déception de voir des horreurs de complexité là où, il y a 50 ans, on faisait déjà mieux.

        • [^] # Re: format/langage PIC

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Note d'humour du vendredi : perso, plus rien ne me surprend depuis qu'on peut proposer un système en bouse de vache (a.k.a QDOS) et passer pour être génial et avoir révolutionné l'informatique… C'est ça le progrès, il fait parfois de grand bonds en arrière avant de faire un minuscule pas en avant.

          :s/humour/humeur

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Unix Text Processing

    Posté par  . Évalué à 7.

    Unix Text Processing est un très bon livre d'initiation à troff et vi. Il date de 1987 et a été écrit par Dale Dougherty et Tim O'Reilly et publié en 1987 par Hayden Books et maintenant disponible sous licence CC BY 1.0.

    https://www.oreilly.com/openbook/utp/

    • [^] # Re: Unix Text Processing

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Merci beaucoup pour ce livre de référence que je ne connaissais pas. Ça va occuper une partie de mon week-end, et je vais probablement découvrir des trucs ou éclaircir des points.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Unix Text Processing

        Posté par  . Évalué à 2.

        Je pense oui, c'est un très bon livre technique comme on en fait plus.

  • # Mom

    Posté par  (site web personnel) . Évalué à 3.

    Merci pour cet éclairage intéressant. Je m'étais penché sur groff il y a quelques temps, me demandant si je n'allais pas l'essayer à la place de LaTeX pour mes quelques documents personnels. Et puis le temps a passé…

    J'avais à l'époque découvert mom qui est un ensemble de macros pour troff. Je voudrais savoir si l'auteur du journal ou quelqu'un d'autre aurait un commentaire sur cet outil : pratique, couche inutile… ?

    • [^] # Re: Mom

      Posté par  . Évalué à 7.

      Les macros mom sont dédiées à des sorties PDF et PS. De ce que je peux lire de la documentation introductive, c'est un ensemble de macros spécifiquement pour les débutants : on peut même oublier les requêtes bas niveau de roff pour se concentrer sur le contenu du document. Et vu le nombre de choses que mom fait, c'est probablement vrai.

      À mon avis pour un débutant qui veut juste produire des documents rapidement, c'est très bien. Ces macros répondent même à certains problèmes que j'ai avec les macros ms, par exemple les liens PDF et les références intra-document sont disponibles de base. La documentation est deux fois plus longue, mais s'ils ont réussi à faire des macros qui remplissent toutes les fonctionnalités qu'on attend, tu gagnes un peu de temps.

      Les noms des macros sont également plus humaines, on peut voir ça avec les noms de chapitres (ou sections) :

      .HEADING 1 NAMED intro "Introduction"

      Voilà, en une ligne on a une nouvelle section, en précisant le niveau de section (1), un mot clé pour le référencement (intro) et le titre. Le tout avec une macro ayant un nom explicite.

      Pour la petite histoire, j'ai débuté avec les macros ms seulement parce que j'avais lu qu'elles étaient plus simples, c'est tout. Au final j'ai jonglé entre différentes documentations (troff, groff et ms) pour comprendre comment tout fonctionnait; et à part les limitations que j'ai vu plus haut, ms c'est très bien aussi. Mais si tu veux te lancer et avoir globalement tout qui fonctionne d'emblée, avec ce que je viens de lire, je pense que c'est plus intéressant de débuter avec mom.

      Si quelqu'un a un retour d'expérience avec mom, hésitez pas.

      • [^] # Re: Mom

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Bien qu'ayant très peu pratiqué la mère (c'est vendredi, on se permet de glisser de mom vers mum pour les similarités), c'est exactement comme ça que je le perçois : c'est la version moderne/évoluée (ciblage PDF/PS mais aussi lisibilité pour les nouveaux et quelques autre fritures) de µ$ (même vendredi on ne devrait pas se permettre ce glissement). Je pense que si on n'est pas très intéressé par les arcanes et qu'on ne prévoit pas de faire des trucs hors clous, il vaut mieux effectivement commencer par ce gosse (oups, je lui ai fait manger un œuf au môme.) Mais il n'est pas réservé qu'aux débutant-e-s : ça convient aussi à des usagers plus avancé-e-s pour produire rapidement des documents qui n'ont pas besoin de structure spécifique pour laquelle on aurait besoin de bidouilles plus bas niveau.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Mom

          Posté par  . Évalué à 3.

          Et je tiens à noter, même si c'est hors sujet, que la personne qui fait mom est aussi celle qui a fait le script d'ajout de polices pour groff. Merci à lui !

  • # Merci !

    Posté par  . Évalué à 4.

    Excellent journal, ça donne envie d'apprendre l'outil (les outils) en effet.

    La simplicité et la pérennité font également partie de mes préoccupations.

    J'ai récemment commencé à utiliser dot/graphviz (car frustré par Draw, Dia, Diagram, Yed…). Pic a l'air chouette !

    • [^] # Re: Merci !

      Posté par  . Évalué à 3.

      Pic est génial, et si tu lis les autres commentaires, tu verras à la fois de code des exemples que j'ai fournis, et une liste d'outils similaires à pic (pour avoir des outils similaires dans d'autres contextes, ou avec quelques fonctionnalités différentes tout en conservant la simplicité de l'outil).

      graphviz c'est très bien quand on a un ensemble de données que l'on veut visualiser sans se soucier du placement. Pic est un peu plus comme dia, pour faire des schémas.

      Ce serait dommage de ne s'arrêter qu'à pic par ailleurs, le reste est également excellent. Sans compter que certaines limitations que j'ai exprimées dans le journal sont levées en utilisant mom plutôt que ms (vieil ensemble de macros, un peu trop limité).

      En tout cas, bonne chance !

  • # Lout

    Posté par  (site web personnel) . Évalué à 3.

    Merci pour cette redécouvertes (pour moi aussi) de Roff et les logiciels associés comme pic.

    Je me suis pas mal intéressé autrefois à Lout. Ce logiciel de formatage de texte tout en un, créé par Jeffrey Kingston, un universitaire australien, semble de nouveau maintenu.

    Si vous voulez voir des exemples

    • [^] # Re: Lout

      Posté par  . Évalué à 2.

      J'ai déjà vu cet outil, mais je n'arrive pas à voir en quoi il serait intéressant. De plus, il m'a l'air quand même bien plus verbeux que troff.

      Dommage qu'il n'y ait pas plus d'exemples, notamment pour faire des diagrammes, des dessins, des graphes…

      • [^] # Re: Lout

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 23 janvier 2022 à 21:50.

        Je l’avais regardé il y a quelques années (déjà suite à un message sur DLFP, si je me souviens bien), et l’absence de support pour les encodages sur plus de 8 bits m’avait refroidi.

        J’ai ré-essayé aujourd’hui, et si j’en juge par les « é » et assimilés qui parsèment le PDF produit, ça n’a pas changé malgré la reprise du développement.

        (Et je trouve la juxtaposition des lignes suivantes dans l’article de la Wikipédia francophone assez ironique :

        • Mûr (Lout a été créé dans les années 1990)
        • Ne gère pas l’UTF-8

        Mûr pour les années 1990 peut-être, mais sûrement pas pour 2022… Au moins roff a preconv.)

      • [^] # Re: Lout

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 23 janvier 2022 à 22:23.

        L'intérêt de Lout est qu'il embarque nativement un tas de fonctionnalités. Effectivement, il est assez verbeux et le @ est assez présent ;)

        À cette adresse, j'ai déposé la doc embarquée avec Lout. Toutes ses fonctionnalités ainsi que ses bases théoriques y sont présentées dans le détail par son concepteur.

        • [^] # Re: Lout

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          la doc embarquée avec Lout.

          Oui, il s'agit du résultat du dossier doc où on peut lire les sources (un sous-répertoire par PDF) https://github.com/william8000/lout/tree/master/doc

          je n'arrive pas à voir en quoi il serait intéressant. De plus, il m'a l'air quand même bien plus verbeux que troff.

          L'intérêt de Lout est qu'il embarque nativement un tas de fonctionnalités.

          Quand on lit le papier sur le design on voit qu'il connait l'univers Troff et parle de Eqn qui l'a inspiré/orienté dans son travail sur les commandes de placement dans Lout.
          Quand on utilise la suite d'outils autour de Troff, on a plusieurs préprocesseurs avec chacun leur langage/syntaxe, ce qui est normal (esprit Unix des outils nés de façon non concertée à des endroits différents, on ressent la même chose avec les options des commandes courantes.) Or l'auteur de Lout a voulu prendre le meilleur de chacun de ces filtres et utiliser une syntaxe unifiée… Et effectivement tout est intégré dans sa solution (sous forme modulaire, et il faut bien veiller à indiquer en préambule les modules à activer)

          Dommage qu'il n'y ait pas plus d'exemples, notamment pour faire des diagrammes, des dessins, des graphes…

          Dans le papier pour les users, on trouve tout au chapitre 9 sur le module Diag que je ne connaissais pas (d'où ma précédente remarque : « Je ne me souviens pas y avoir vu d'équivalent à MetaPost ou à Tikz, et donc rien qui serait comparable à Pic… » qui devient maintenant caduque.) C'est fortement inspiré de Pic et étendu (après tout, pourquoi s'arrêter en si bon chemin ?) avec des trucs comme @Isoceles, @Square, @polygon, @Diamond, @CurveBox, etc. Voici un arbre binaire donné en exemple 

          @Tree {
  @Circle A
  @LeftSub {
    @Circle B
    @LeftSub @Square C
    @RightSub @Square D
  }
  @RightSub @Circle E
}

          …et que je retranscris ainsi en ASCII-art

                  (A)
       /   \
    (B)     (E)
   /   \
[C]     [D]

          La section 9.2 qui commence à la page 221 dresse un inventaire illustré vraiment pas mal je trouve.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Lout

            Posté par  . Évalué à 2.

            J'apprécie ce qu'il est possible de faire avec l'outil, mais je préfère l'approche de troff. Lout est un bon logiciel, mais comment rivaliser avec le charme des outils unix ?

            Je me demande quel est l'apport fonctionnel de Lout par rapport à troff. Des formats de pages plus complexes en gardant un code simple ? Un niveau de précision plus important concernant les dessins ? Des tableaux plus complexes ? Des graphes plus évolués ?

            En regardant la section que tu as mentionné, en effet, il y a quelques constructions intéressantes, comme la gestion des séquences. C'est bel et bien un type de dessins qu'on pourrait vouloir dans un document. Maintenant, est-ce que l'approche de Lout est la meilleure pour ça ? Je préférerai de très loin une extension de pic pour faire la même chose.

      • [^] # Re: Lout

        Posté par  (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 23 janvier 2022 à 23:07.

        C'est un peu plus verbeux que Troff, mais beaucoup moins que XML (DocBook et consorts) et parfois un chouia moins que LaTeX auquel il répond en se voulant plus simple. Du coup, Par rapport à Troff, pour comparer au même niveau, il faudrait comparer à Mom… :-) Par rapport à sa cible (des gens qui cherchent un balisage simple sans avoir besoin de tout ce que LaTeX peut offrir, des gens qui se tournent souvent vers trucs étendant Markdown) Lout fait le boulot (hormis l'absence cruelle d'Unicode pour arriver à plus s'imposer.)

        Je ne me souviens pas y avoir vu d'équivalent à MetaPost ou à Tikz, et donc rien qui serait comparable à Pic…

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Lout

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          C'est un peu plus verbeux que Troff, mais beaucoup moins que XML (DocBook et consorts)

          Alors, je suis d'accord que Docbook est verbeux en raison du XML mais contrairement aux outils présentés ici, il ne s'agit pas que d'un formatteur.
          En effet, les balises portent une sémantique pour le fond et un peu pour la forme.
          Cela permet notamment d'utiliser sur le source des outils comme XPath pour extraire, par exemple, tous les noms de programmes mentionnés dans le document.

          Mais oui, c'est verbeux et il est parfois compliqué de choisir la bonne balise.

          • [^] # Re: Lout

            Posté par  . Évalué à 3.

            Pour moi l'utilisation de XML est rédhibitoire. Même en tant que simple format intermédiaire de sérialisation je suis contre.

            Pour troff, récupérer des noms de programmes dans le texte :

            soelim doc.ms | grep "^.APPLICATION"

            Pas besoin d'outils spécialisés.

            • [^] # Re: Lout

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Pour moi l'utilisation de XML est rédhibitoire. Même en tant que simple format intermédiaire de sérialisation je suis contre.

              Pas de souci, il est vrai que le rapport signal/bruit n'est pas très bon.
              Le seul avantage par rapport à d'autres formats, c'est qu'il y a une grammaire et que l'on peut donc valider le document.

              Pas besoin d'outils spécialisés.

              Ben soelim, ce n'en est pas un peut-être ? :D

              Quant à XPath, ça ne permet pas que de récupérer les noms de programmes dans le texte mais aussi les noms de programmes mentionnés dans les see also ou en tant que termes d'un glossaire.

              Mais je comprends tout à fait ta préférence pour troff et je ne remets pas du tout ton choix en cause, y a aucun problème :)

              • [^] # Re: Lout

                Posté par  . Évalué à 3.

                Attention, soelim est fourni de base avec troff, et pourrait être réimplémenté en 5 lignes de code. ;) Et au pire, tu peux t'en passer et faire un grep -R, ce sera juste pas dans l'ordre.

                Quant à XPath, ça ne permet pas que de récupérer les noms de programmes dans le texte mais aussi les noms de programmes mentionnés dans les see also ou en tant que termes d'un glossaire.

                Je n'ai pas compris. Je ne connais pas le fonctionnement de DocBook.

                Je suppose que see also est une section balisée comme telle dans DocBook. Si c'est le cas, il n'y a pas d'équivalent à ce que tu dis dans troff. Cette section pourrait être implémentée entre deux appels de macros .SEE_ALSO1 et .SEE_ALSO2 et à l'intérieur tu pourrais y mettre l'appel à .APPLICATION comme partout ailleurs.

                • [^] # Re: Lout

                  Posté par  (site web personnel, Mastodon) . Évalué à 10.

                  Quant à XPath, ça ne permet pas que de récupérer les noms de programmes dans le texte mais aussi les noms de programmes mentionnés dans les see also ou en tant que termes d'un glossaire.

                  Je n'ai pas compris. Je ne connais pas le fonctionnement de DocBook.

                  Ce qu'il voulait dire, c'est que XML et SGML ne sont pas qu'une famille de format de balisage et/ou de description de documents. Ce sont d'abord des « grammaire » pour décrire des structures arborescentes (ce qui s'applique bien à des « documents structurés » mais est tout à l'opposé des langages de description de pages pour lesquels les formats de description de pages —comme TeX/TROff/RTF/etc.— sont des abstractions plus hauts niveau.) Ces grammaires sont distribuées dans une forme normalisée (XML Schema puis ReLaX NG ainsi que DTD plus historiquement) et ne sont plus des grammaires incorporées dans les outils (et documentées en syntaxe BN par exemple.) Du coup c'est très bien comme format d'échange, mais je m'égares un peu.
                  Outre la validation, cette arborescence peut être simplement interrogée/requêtée et c'est ce que formalisent XPath et XQuery.
                  De la même façon, on peut mettre en œuvre des transformations d'une grammaire en une autre en utilisant XSLT et indiquer avec XSL-FO les règles générales de présentation ; ce qui la rend la chose encore meilleur comme format d'échange, mais je m'éloigne trop.

                  Ceci sont valables pour tous les documents XML. On peut avoir des XML pour une base de données bibliographique, pour sa collection de timbres, pour du dessins vectoriel (c'est le cas avec SVG), pour du texte structuré (c'est le cas avec les formats OpenDocument, epub, TEI et DocBook…)

                  Je suppose que see also est une section balisée comme telle dans DocBook. Si c'est le cas, il n'y a pas d'équivalent à ce que tu dis dans troff. Cette section pourrait être implémentée entre deux appels de macros .SEE_ALSO1 et .SEE_ALSO2 et à l'intérieur tu pourrais y mettre l'appel à .APPLICATION comme partout ailleurs

                  C'est un peu l'idée mais en plus subtile. Comme les index et les différentes tables (illustrations, tableaux, etc.) tu peux donc avoir une section VoirAussi avec une sous-section Logiciels (ou juste une section Index des programmes…) où les programmes ne sont pas référencés comme dans le corps du document (car pas besoin de mise en page/évidence particulière) mais on sait facilement récupérer cette liste …en plus des éléments ailleurs.

                  Bref, XML est utilisé et devrait être la norme (d'échanges) dans les systèmes de traitement documentaires. Ce genre de système (pense par exemple au catalogue de la BNF ou tout système où on doit pouvoir indexer finement et réorganiser programmatiquement de larges volumes) n'a pas de lien avec son propre système de documentation (écrire ses rapports/mémoires/livres) et de toute façon, XML est ingérable à la main (i.e. dans un simple éditeur de texte par exemple.) Je milite pour l'emploie de XML mais il n'est pas dans mon workflow personnel.

                  “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: Lout

                Posté par  (site web personnel) . Évalué à 3. Dernière modification le 06 février 2022 à 12:21.

                Le seul avantage [de XML] par rapport à d'autres formats, c'est qu'il y a une grammaire et que l'on peut donc valider le document.

                Il y a aussi la prise en charge des espaces de noms…

                Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

  • # "Pour ma thèse, j'ai utilisé LaTeX, comme tout le monde."

    Posté par  (site web personnel) . Évalué à 3.

    Pour ma thèse, j'ai utilisé LaTeX, comme tout le monde.

    Tout le monde dans le milieu scientifique, peut-être… mais dans mon université (plutôt "sciences humaines") je pense que la proportion doit être inversée…

    J'ai un peu découvert l'existence de Troff il y a quelques années dans un livre, je ne sais plus lequel(peut-être "systèmes d'exploitation" de Tanenbaum?), en tous cas je n'avais pas compris grand chose…

    L'idéal serait que tu en fasses une conférence, comme celles géniales de Thierry Stoher sur le "orgmode" à PSES.

    Digression à propos du (X)HTML qui a été évoqué: je crois que le truc qui m'agace le plus avec, c'est l'apparente redondance des balises title et h1

    • [^] # Re: "Pour ma thèse, j'ai utilisé LaTeX, comme tout le monde."

      Posté par  . Évalué à 4.

      Ce serait effectivement intéressant d'en faire une vidéo. Je pense que ce serait mieux de l'adapter au format web plutôt qu'en faire une conférence. J'ai présenté le langage Zig de cette manière (en anglais).

      J'ai déjà vu quelques vidéos sur le sujet, mais pas forcément de très bonne qualité audio, parfois trop survolé, et jamais en Français. Donc oui, cela demande un peu de temps, mais ce serait une bonne chose, et je peux faire ça (abonne-toi, met la cloche).

      • [^] # Re: "Pour ma thèse, j'ai utilisé LaTeX, comme tout le monde."

        Posté par  (site web personnel) . Évalué à 2.

        Oh non, ce n'est pas une plate-forme libre ça!!! Moi je préfère le présentiel, enfin si un jour ça redevient sérieusement possible.

        Le livre ça devait être "Système Linux" en fait, offert par un libriste.

        • [^] # Re: "Pour ma thèse, j'ai utilisé LaTeX, comme tout le monde."

          Posté par  . Évalué à 4.

          Pour le présentiel, je ne suis pas fan. C'est assez long et fastidieux d'un point de vue de l'organisation, et le produit final n'est pas aussi agréable qu'une vidéo avec des schémas et le loisir de choisir le rythme. J'apprécie davantage une vidéo explicative, longue ou courte, plutôt qu'une heure de « cours » où on passe du temps à gérer une salle (avec plein de problèmes liés : gestion du bruit des participants, captation du son ± acceptable mais souvent pas terrible, captation de l'image souvent désastreuse…) plutôt qu'à rendre son contenu attractif.

          Niveau plateforme, je peux aussi diffuser ça sur un peertube. En vrai, mes vidéos pourraient être retransmises ailleurs, je publie pour l'instant en CC.

  • # utroff

    Posté par  . Évalué à 4.

    si Sygne est toujours parmi nous, je veux bien savoir si son projet utroff est toujours pertinent. Il en avait fait des dépêches il y a maintenant 8 ans, et le site est malheureusement hors ligne maintenant.

    A priori le site est maintenant ici.

    Suite à ton journal je viens de tester groff avec mom pour produire une documentation assez courte au format PDF (3 pages). L'outil est assez plaisant à utiliser, merci pour cette découverte. Il ne me reste plus qu'à apprendre à l'utiliser.

    • [^] # Re: utroff

      Posté par  . Évalué à 5.

      Merci merci merci ! Je suis vraiment content d'apprendre que le projet utroff est toujours maintenu !

      Content également de voir que roff te plaît ! J'espère que l'outil te satisfera. Même avec les limitations décrites dans le journal j'en suis satisfait. Et avec mom et un peu de bidouille pour l'intégration des images, ce sera parfait pour moi. Je ferai un autre journal pour compléter celui-ci.

      En tout cas, je n'espérais pas un aussi bon retour sur ce journal. C'est une agréable surprise.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.