Groff sort en version 1.21

Posté par  (site web personnel) . Modéré par patrick_g.
37
17
jan.
2011
GNU
C'est le 31 décembre 2010 que Werner Lemberg, le principal mainteneur de groff, a annoncé la sortie de la version 1.21, soit près de deux ans après la sortie de la précédente version.

Pour rappel, groff est l'implémentation GNU de l'ancestral logiciel roff, interpréteur du langage de formatage de texte du même nom. Groff est généralement utilisé sur nos machines pour afficher nos pages de manuel, mais, outre la sortie en ASCII, latin1 ou UTF-8, groff peut aussi créer des fichiers HTML, xhtml, dvi, PS, ainsi que des fichiers aux formats spécifiques à certaines imprimantes.

Voici quelques-unes des améliorations apportées par cette nouvelle version:
  • Correction d'une petite faute dans tmac/hyphen.fr qui rendait impossible la césure des lignes des textes français ;
  • Ajout d'une nouvelle catégorie d'alarme nommée file pour indiquer l'absence d'un fichier appelé par mso ;
  • Amélioration du support des langues asiatiques et en particulier du japonais. C'est d'ailleurs cette amélioration importante qui a motivé Werner Lemberg à publier cette nouvelle version de groff ;
  • Création d'une nouvelle catégorie de piège (trap) actionnable lorsqu'une ligne commence par un espace, sous réserve que soit définie la macro lsm. Le saut de ligne qui advient normalement dans ce cas n'a alors pas lieu.

En seconde partie de dépêche est proposée une plus large présentation de groff et de son histoire.

1. Histoire de roff

1.1 RUNOFF

C'est en 1964, sur le CTSS du MIT, qu'est apparu le premier programme de formatage de texte : RUNOFF, écrit par Jerome H. Saltzer. Le nom est supposé venir de la locution anglaise : « I'll run off a copy ».

1.2 Runoff

Pour Multics, le digne successeur du CTSS, le logiciel a été récrit par Jerome H. Saltzer, Bob Morris et Doug Mc Ilroy et renommé runoff (en minuscules). De nombreux logiciels incompatibles entre eux copiant l'usage de runoff sont alors apparus sur diverses architectures.

1.3 Roff

Le code de runoff a alors été translittéré par Josef F. Osanna – déjà développeur de plusieurs ports de runoff, – pour le prototype d'Unix fonctionnant sur le DEC PDP-7 en 1970, et renommé roff, puis récrit pour le PDP-11 en 1971. Dennis Ritchie remarque que ce logiciel, rapidement modifiable et répondant aux besoins du département des brevets de Bell Labs, a été une des raisons provoquant l'adoption d'UNIX au sein de l'entreprise.

1.4 Nroff et troff

Mais Josef Osanna ne s'est pas contenté de translittérer le code, il a ensuite récrit le programme en C et y a ajouté de nombreuses fonctionnalités. Il a alors décomposé le logiciel en deux programmes : nroff (newer roff) pour les terminaux et les imprimantes lignes à lignes et troff (typesetter roff) pour les documents devant être imprimés, une unique imprimante était alors supportée. En 1976, il publie avec son collègue Josef Osanna le Troff User's Manual qui sert de spécification du langage roff. De fait, toutes les implémentations futures de roff tenteront de conserver une compatibilité avec cet écosystème originel et son langage de formatage de texte.

1.5 Ditroff

À la mort de Josef Osanna en 1977, c'est Brian Kernighan qui développe troff et nroff, ce qui passe par une nouvelle récriture du logiciel. Il modifie à nouveau l'architecture du système, en créant un logiciel générique, ditroff (device independant troff), produisant une sortie intermédiaire traitée ensuite par différents post-processeurs. Ce format de sortie intermédiaire est défini dans un document qui fait encore aujourd'hui office de référence.

1.6 La multiplication des *roff

Avec le développement d'UNIX à la fin des années 70 le logiciel troff est largement copié et modifié, mais heureusement, ces différentes versions prennent soin de conserver la compatibilité avec le logiciel d'Osanna et Kernighan. Retenons parmi celles-ci :
  • DWB (document workbench) de SoftQuad ;
  • DWB 3.4 de Lucent Software Solutions ;
  • Le troff de Plan9 ;
  • La version de Bill Joy, vendue par Sun Microsystem, et dont un descendant équipe les Solaris ;
  • Cette dernière version a été libérée en 2005 avec le code d'Open Solaris, retravaillée par Gunar Ritter pour le Heirloom Project et distribuée sous le nom Heirloom Troff (Le troff des souvenirs). M. Ritter y ajoute le support des polices open-type, la gestion de l'UTF-8 et y inclut des fonctions de micro-typographies, dont l'algorithme de Knuth-Plass créé pour LaTeX pour la mise en forme des paragraphes.

1.7 Groff


C'est en 1990 qu'est sortie la première version de groff, récriture de troff en C++ par James Clark pour le projet GNU. Les actuels mainteneurs de Groff, Werner Lemberg et Ted Harding prennent soin de celui-ci depuis 1999.

1.8 La fin de l'âge d'or des *roff

L'usage de Roff et de ses descendants est en forte perte de vitesse depuis plusieurs années pour plusieurs raisons: l'adoption de LaTeX dans le milieu universitaire, la concurrence des logiciels de traitement de texte, la création d'outils plus génériques pour le formatage de texte tels txt2tag et la pauvreté de l'offre de macro pour roff. Même pour l'affichage des pages de manuels, terrain où groff semblait incontournable, les distributions ont tendance à préférer des outils concentrés sur cette tâche: Debian propose par défaut groff-base, une implémentation réduite de groff, FreeBSD choisit mdocml alors qu'ils auraient pu choisir Heirloom Troff qui est sous licence BSD. Pourtant, l'écosystème roff réunit toujours une communauté d'utilisateurs et de développeurs, qui se rencontrent sur la mailing list de groff, et qui, sans se faire d'illusion pour l'avenir de roff, savent mettre en avant la spécificité et les avantages comparés de groff et de LaTeX (voir ce long fil de discussion, et en particulier ce message et celui-ci).

2. L'écosystème groff

Dans l'archive de groff se cache en fait une foule de programmes et de macros. groff n'étant que le logiciel qui permet, en une ligne de commande, d'accorder cet écosystème logiciel. L'archive contient donc des pré-processeurs, des processeurs, des post-processeurs, des outils divers et des macros.

2.1 Pré-processeurs

Les pré-processeurs transforment un fichier source que l'on peut écrire à la main en langage roff moins pratique à taper. Ainsi, tbl simplifie l'écriture des tableaux, refer celle des références bibliographiques, eqn des formules mathématiques, pic des diagrammes, chem celle des structures chimiques. Parmi les pré-processeurs, citons aussi preconv, qui convertit des sources de formats d'encodage divers en quelque chose que groff peut comprendre et traiter.

2.2 Processeur

Le processeur interprète le langage roff. Comme le ditroff historique, il produit une sortie intermédiaire qui sera traitée pour la création de fichiers plus complexes, mais le mot ditroff n'a pas survécu, les développeurs préférant l'appeler troff en référence au logiciel original. Le manuel de groff considère aussi nroff comme un processeur, bien qu'il s'agisse en fait d'un script shell qui émule le nroff historique: il est utilisé pour l'affichage de texte brut (ASCII, latin1 ou utf8).

2.3 Post-processeurs

Les post-processeurs traitent la sortie intermédiaire pour produire des fichiers complexes: grotty pour les sorties en texte brut (c'est le post-processeur utilisé par nroff), grodvi pour le dvi, post-grohtml pour le HTML et le XHTML, grops pour le PostScript, grolpb et grolj4 pour les formats d'imprimantes lpb et lj4.

2.4 Outils divers

D'autres petits outils facilitant l'usage quotidien de l'écosystème roff sont fournis: indxbib, lkbib et lookbib pour gérer les références bibliographiques, afmtodit et tfmtodit pour les polices, grog qui détermine la commande groff à appliquer pour mettre en forme le fichier qui lui est proposé en entrée, etc.

2.5 Macros

Enfin, l'archive contient des macros. Roff est un langage de formatage de texte, les macros sont des logiciels composés dans ce langage. Roff est moins utilisé que ne l'est Tex, aussi, ces macros sont moins développées que ne le sont LaTeX ou XeTex, néanmoins, elles ont l'avantage de n'être pas très difficiles à modifier. Les usagers avertis de groff, plutôt que de chercher la macro qui va bien, sont habitués à la créer sur mesure. Citons, parmi les macros les plus connues: man, doc et mdoc, qui sont faites pour les pages de manuel, me, mm et ms, macros ancestrales, récrites pour groff, qui permettent d'écrire des lettres, de la documentation, ou votre thèse de philosophie, www qui permet de personnaliser les fichiers HTML produits par Groff, et mom, macro généraliste et largement configurable, créée à l'origine pour l'écriture d'un roman.

3. Utiliser groff

3.1 Philosophie Unix

Cet ensemble d'outils a d'abord été construit selon les principes de la philosophie Unix où un outil est dédié à une tâche, où chaque programme est pensé comme filtre entre des données d'entrées et des données de sorties. La meilleure introduction à Roff est d'ailleurs l'ouvrage Unix text processing, de Dale Rougherty et Tim O'Reilly, dont le but est de montrer que les outils Unix forment une interface souple et performante pour la composition de textes. Dès lors, mettre en forme un fichier composé en roff via la macro ms et contenant des tableaux, des équations et des références bibliographiques suppose d'utiliser une longue ligne de commande :
cat /path/to/ms.tmac fichier | eqn | tbl | refer | troff | grops > fichier.ps
Ce que groff peut résumer par:
groff -m ms -etR fichier > fichier.ps
Ou par:
`grog fichier` > fichier.ps

3.2 Exemple

Nous pouvons, maintenant, composer un fichier au format roff utilisant la macro ms:
.\" fichier.ms
.\" Document exemple
.\" à mettre en forme ainsi:
.\" `grog fichier.ms` > fichier.ps
.TL
Document d'exemple
.AU
Sygne@dlfp
.NH 1
Exemples divers
.NH 2
Exemple de paragraphe
.PP
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Sed non risus. Suspendisse lectus tortor, dignissim sitamet,
adipiscing nec, ultricies sed, dolor.*
.FS *
Note de bas de page entre
FS (Footnote Start) et
FE (Footnote End).
.FE
.NH 2
Exemple de citations
.R1
database biblio.ref
.R2
.PP
Un texte référencé.
.[
utp
.]
Un autre texte référencé.
.[
programming
.]
.NH 2
Exemple de tableau
.PP
.TS
box center tab(|);
ccc,lcr,rlc.
center|center|center
left|center|right
right|left|center
.TE
.NH 2
Exemple de formule mathématique
.EQ
lim from {m -> inf} sum from i=0 to m c sup i
.EN
.\" Fin provisoire de fichier.ms

Pour que les références bibliographiques s'affichent, il faut composer le fichier de références biblio.ref ainsi:
# biblio.ref
%L utp
%T Unix Text Processing
%A Dale Dougherty
%A Tim O'Reilly
%C Indianapolis
%I Hayden Books
%D 1987

%T The Unix Programming environment
%A Brian W. Kernighan
%A Rob Pike

%T Dieu sans l'être
%A Jean-Luc Marion
%C Paris
%I PUF
%D 1991

# fin de biblio.ref

La puissance de l'écosystème roff n'est véritablement sensible que lorsque l'utilisateur est capable d'écrire ses propres macros. Pour apprendre à écrire des macros roff, la lecture de Unix Text Processing est indispensable, mais, en guise de mise en bouche, voici quelques exemples:
# suite de fichier.ms
.NH 1
Exemples de macros personnelles
.de PONCTUATION
.\" insère les espaces corrects
.\" espace insécable:
.char : \~:
.\" espaces fines insécables:
.char ; \|;
.char ? \|?
.char ! \|!
.char \[Fo] \[Fo]\|
.char \[Fc] \|\[Fc]
..
.de CROIX
.\" rature un mot d'une croix
.\" .s: point size of text
.\" \Z' word' : print word with 0 width and height
.\" \D'l x y': draw a line until point (x;y)
.\" \h' x': move horizontaly of x units.
.\" \w'\$1': length of word $1
.nr size (\\n[.s]*75/100)
\Z'\\$1'\D'l \w'\\$1'u -\\n[size]p'\h' -\w'\\$1'u\v' 1m'\D'l \w'\\$1'u \\n[size]p'
..
.NH 2
Exemple de ponctuation
.PONCTUATION
.PP
Mais que dire? Rien?! Non, il faut dire cela:
«Ne rien dire, c'est tout dire; tout dire, c'est ne rien
dire!»
.NH 2
Exemple de mot barré
.PP
«Le nom de
.CROIX Dieu
qui se croise parce qu'il se crucifie, relève-t-il
de l'être?»
.[
Dieu
%P 106
.]
.\" Fin de fichier.ms

Pour en savoir plus, vous pouvez consulter :

Aller plus loin

  • # Intéressant...

    Posté par  . Évalué à 1.

    ...cependant, j'ai été obligé de changer 'database' en 'bibliographie' pour le champ R1 dans fichier.ms afin d'avoir un premier rendu. Mais l'article est vraiment bien rédigé. Merci à vous.
    • [^] # Re: Intéressant...

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

      Merci!

      Normalement, la commande 'database' indique à refer où chercher la liste des références, et la macro ms utilisée ici affiche alors celles-ci en note de bas de page.

      À la lecture de la commande 'bibliography' refer liste toutes les références, ce qui est utile en fin de document.

      Chez moi ça marche! (hormis quelques typos corrigées plus bas)
  • # Typos

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

    Il y a quelques fautes, dont deux qui affectent le code des exemples:

    collègue Josef Osanna -> collègue Brian Kernighan
    txt2tags -> txt2tags,
    . groff -> . Groff
    par Groff -> par groff
    Dieu sans l'être -> Dieu sans l'\[e ^]tre
    # suite -> .\" suite

    Merci à l'équipe pour l'introduction des balises de titre et les autres corrections!
    • [^] # Re: Typos

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

      Typos aisément pardonnés pour une dépêche très bien rédigée. Comme quoi le style de patrick_g peut faire des émules !
      En effet, sur un sujet pas très sexy, la nouvelle se lit comme un roman et est fort bien documentée.

      En cette époque de vœux, je fais celui de voir beaucoup de nouvelles de cette qualité.
  • # Syntaxe

    Posté par  . Évalué à 4.

    Je suis le seul à trouver cette syntaxe ignoble ?

    J'imagine bien que ça se parse facilement, mais c'est nettement moins agréable à utiliser que LaTeX, même lout me semble plus agréable (alors que lout n'est pas terrible).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Syntaxe

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

      La syntaxe est d'un autre âge mais l'outil est bien pratique. J'ai horreur des programmes qui n'ont pas de "man" et du coté des applications graphiques, cela arrive de plus en plus souvent.

      Je faisais pas mal de man en pod (Perl). La commande pod2man transforme alors le fichier de roff que "man" sais lire. Cela permet de vite faire de la doc, propre et utilisable.
      • [^] # Re: Syntaxe

        Posté par  . Évalué à 3.

        Si c'est juste pour générer des pages manuels (je suis d'accord avec toit que tout les logiciels devraient avoir au minimum une page man) autant utiliser quelque chose comme txt2tags qui le fait en natif aussi. Désolé d'encore insister sur txt2tags, mais il faut vraiment avoir des arguments forts pour faire face à des outils comme LaTeX (qualité de typographie et de mise en page) ou les markup languages (agréable à écrire).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Syntaxe

          Posté par  . Évalué à 2.

          Markdown sait faire aussi (avec ronn)
        • [^] # Re: Syntaxe

          Posté par  . Évalué à 3.

          Je doute que txt2tags fasse des pages manuel en natif... il doit tout au plus faire du texte formaté selon un jeu de macros *roff (man) qui, utilisé par *roff, permet de formater des pages de manuel. Il est donc au mieux au dessus de *roff, mais en aucun cas ne s'y substitue ; je parierais même qu'il n'offre qu'une petite partie des possibilités du jeu man.

          Pour ce qui est de LaTeX, il y a de bons arguments en faveur de Groff : peu d'encombrement par rapport à une distro LaTeX (rapport 1 contre 200, même avec une installation LaTeX au cordeau), disponible quasiment partout en standard pour les macros basées troff et, surtout, la possibilité d'une sortie sur terminal ; pour tous les petits documents, c'est vraiment génial de pouvoir les lire directement sans passer par un format et un lecteur (pdf, dvi, html) intermédiaires.

          Bien sûr, la syntaxe paraît horrible, mais un texte de base LaTeX est aussi une horreur dès qu'on cherche à faire quelque chose de chiadé ; c'est pas pour rien qu'il y tant de classes de document et de paquets de macros LaTeX, mais tout simplement parce que la maîtrise des macros est indispensable pour se servir sérieusement de ce genre d'outil et commencer à s'amuser. De plus l'exemple *roff montré est issu d'un très vieux paquet de macros, maintenu tel quel en raison de vieilles compatibilités ; man est beaucoup plus propre et parfaitement utilisable en direct.

          Merci à l'auteur de la dépêche d'avoir pris le temps de mettre en avant les macros ms, ça fait longtemps que je cherche un moyen décentralisé de formater et lire mes notes sans me coltiner la synchronisation source <-> sortie et passant outre la rigidité formelle de man . La seule chose un peu gênante, qui l'est déjà avec man, c'est qu'il semble impossible de spécifier dans le document source l'encodage de celui-ci ; résultat, sur un device utf8, un source UTF-8 est encodé deux fois lors de l'affichage... enfin, ça doit pouvoir se contourner, et c'est indéniablement une piste à creuser. :)
          • [^] # Re: Syntaxe

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

            Un des avantages de *roff est d'avoir une sortie terminal. Je pense que si LaTeX avait été conçu pour avoir une sortie dans le terminal, roff aurait disparu. Mais justement, pour moi, les deux ne sont pas incompatible mais tout à fait complémentaire.

            A noter qu'avec les wikis en abondance de nos jours, tout le monde va nous dire que sa syntaxe wiki est meilleure et tout et tout.

            Moi je faisais du pod car à l'époque, les wikis n'existait pas et c'était déjà intégré dans Perl. C'est très très simple et pour faire des pages de man, c'est suffisant car je veux un affichage simple dans le terminal. En plus, tous mes modules Perl sont documentés ainsi. C'est vraiment important d'avoir la doc minimale dans le code source.

            Après, les syntaxes wiki, c'est bien mais j'en utilise 36, du coup, il me faut presque toujours une doc sous la main pour avoir les spécificités de la syntaxe d'un wiki particulier. Et comme il n'y en pas une qui se dégage du lot et que j'en trouve aucune parfaite, c'est pas près de changer.
            • [^] # Re: Syntaxe

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

              > Après, les syntaxes wiki, c'est bien mais j'en utilise 36, du coup, il me faut presque toujours une doc sous la main pour avoir les spécificités de la syntaxe d'un wiki particulier. Et comme il n'y en pas une qui se dégage du lot et que j'en trouve aucune parfaite, c'est pas près de changer.

              J'ai l'impression, peut-être fausse, que la syntaxe markdown sort un peu du lot et que c'est la syntaxe wiki que l'on retrouve le plus fréquemment. Et comme c'est une syntaxe que je trouve acceptable (pas parfaite, ni même ma préférée), c'est la syntaxe que j'utilise quand j'ai le choix.

              Une autre bonne raison d'utiliser markdown est que ça va être la syntaxe utilisée pour les contenus et commentaires sur LinuxFr.org dans sa prochaine version.
              • [^] # Re: Syntaxe

                Posté par  . Évalué à 1.

                +1

                Markdown est vraiment bien pensée, àmha ; partir du mail était vraiment une bonne idée. Les seuls reproches que je lui ferais sont de contraindre l'indentation du source en en faisant une clé de formatage pour le verbatim (j'ai horreur qu'on contraigne l'indentation du texte que je tape), et peut-être, mais c'est moins grave, d'avoir un formatage de base flottant (on peut par exemple user de ** ou de * pour produire du gras).

                Par contre, je ne suis pas sûr qu'on la retrouve aussi fréquemment que ça. Il faut bien voir que les clés de balisage doivent être prises dans l'ASCII de base pour être portables ; ce qui une fois qu'on a retiré l'alphabet et les chiffres doit laisser tout au plus une trentaine de caractères ; il n'est partant guère étonnant que toutes les syntaxes wiki se ressemblent. :)
              • [^] # Re: Syntaxe

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

                Syntaxe que j'utilise presque tous les jours :

                - SPIP
                - Trac
                - Ikiwiki (markdown pour moi)
                - Mediawiki

                Pour les utilisateurs, c'est pas idéal.
            • [^] # Re: Syntaxe

              Posté par  . Évalué à 2.

              La syntaxe wiki est loin d'être parfaite. Ce que je lui reproche le plus c'est d'avoir une grande part d'implicite dans certains.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Syntaxe

            Posté par  . Évalué à 3.

            Merci j'avais vraiment du mal à voir les avantages de *roff (bien que sur le site ils annonce man sans autre précision).

            Pour txt2tags tu as raison. Mais je doute que tu es besoin de retoucher le *roff, vu que dans une sortie terminal, la mise en page est relativement pauvre (gras, hypertexte,...) sauf peut être pour le centrage, en tout cas la plupart des cas.

            Donc en résumé, groff est un langage de macro qui permet de produire des documents (xhtml, dvi, ps,...) à partir d'un (ou plusieurs) fichier texte. C'est un logiciel simple et léger sur disque qui permet de créer une sortie "texte brut" (c'est quoi le format ?) qui permet de créer des documents lisibles comme on lis des manpages.

            Pour ce qui est de la syntaxe de LaTeX, elle est tout de même beaucoup moins cryptique de celle de groff.

            En tout cas merci j'essaierais à l'occasion.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Syntaxe

              Posté par  . Évalué à 2.

              De rien. :)

              Pour ce qui est de la comparaison avec la syntaxe LateX, il serait plus fair-play de faire une comparaison avec TeX, question de génération. Mais même avec LaTeX, il suffit de jeter un œil à par exemple article.cls (fichier de classe), pour être saisi d'effroi.

              Au delà, c'est question de goût ; personnellement et tout en me débrouillant avec la fabrication de macros et de classes , je trouve LaTeX trop verbeux et j'ai de plus en plus en horreur le balisage via contre-obliques, crochets et accolades (sur un clavier azerty, ça relève de la torture). *roff tombant quant à lui plus ou moins dans les mêmes travers (l'obligation de mettre les macros en début de ligne étant àmha sa tare propre), j'ai tendance à mettre les deux formats à égalité.

              En fait, je les pratique plus comme format cible que comme format source, car ce n'est guère difficile de faire des choses à la markdown (traiter le formatage courant en wiki et laisser passer le code plus complexe) avec ce type de format ; il suffit de savoir ce qu'on veut obtenir en sortie.
              • [^] # Re: Syntaxe

                Posté par  . Évalué à 2.

                C'est probablement une question de goût, mais comme j'ai affaire à des gens qui on peur à l'idée d'écrire une document dans un fichier texte qui seras par la suite parsé/compilé vers un fichier ps ou pdf, je pense que la documentation de LaTeX ainsi que la lisibilité induite par sa verbosité (\section{Bidule}) sont un atout en environnement hostile.

                Mais comme dis, je sais plus où. La méthode qui semble la plus en vogue actuellement c'est d'utiliser markdown, restructured ou txt2tags pour ensuite générer plus ou moins ce que l'on veux, avec l'inconvénient que l'on utilise le plus petit dénominateur commun en terme de fonctionnalité.. en même temps quand on parle de LaTeX.

                D'ailleurs Groff fait des choses """simples""" où il est possible de faire du dessins par exemple, du multicolonne, gestion des images, gestion des formules mathématiques, etc....

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Syntaxe

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

                Je plussoie la distinction entre LaTex et Tex pour la comparaison avec Groff, et précise:

                - S'il faut comparer *roff avec quelque chose, c'est avec Tex. Il n'est pas certain que *roff soit perdant dans cette comparaison - pensez à Heirloom Troff, qui intègre les fonctions de micro-typographie, supporte les polices open-type et l'utf8 nativement.

                - S'il faut comparer LaTeX avec quelque chose, c'est avec l'une des macros *roff. Là, pour le coup, LaTeX sort tout de suite gagnant, car les macros *roff sont peu étendues. Mais, il n'est probablement pas impossible de créer une macro *roff à la hauteur de LaTeX ou XeTeX.

                Concernant la syntaxe il me semble important de rappeller qu'elle est largement définie par la macro utilisée (hormis pour le retour à la ligne imposé). La macro mom utilise par exemple des mots entiers (AUTHOR, DOCTYPE, FROM, GREETING, etc.).

                D'autre part, il est possible de modifier l'opérateur signalant une macro ('.' par défaut). Dès lors, on pourrait préférer l'opérateur < et créer les macros p>, h1>, ul>, etc., pour ouvrir une séquence, et les macros /p>, /h1>, /ul>, etc., pour la fermer. Et pour le coup, une simple ligne sed permet d'introduire les retours à la ligne là où il faut.
    • [^] # Re: Syntaxe

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

      Je me suis fait la même réflexion la première fois que j'ai vu un document *roff, mais à l'usage, je finis par l'apprécier cette syntaxe - sans vraiment savoir pourquoi.

      C'est un peu comme python: elle force l'aspect visuel du fichier source, et avec un peu d'habitude, on finit par s'y retrouver très vite. Les lignes des fichiers *roff sont généralement courtes, ce qui rend le code des macros, AMHA, agréable à lire.

      Pour respecter cet esprit, quand je tape un texte pour *roff, vim force le retour de ligne à 60 caractères, et j'ai pris l'habitude de travailler avec deux colonnes.

      Par contre, c'est vrai que toutes les commandes inline, celles qui utilisent le \ sont illisibles.
      • [^] # Re: Syntaxe

        Posté par  . Évalué à 2.

        Marrant, personnellement j'ai plus de problèmes à employer les macro .B, .BI, etc. que les opérateurs de fonte. Ceci me paraît plus naturel :

        Du \fBtexte gras\fR en démo.

        Que cela :

        Du
        .B texte gras
        en démo.


        Question d'habitude, sans doute (les opérateurs font plus « langage à balise » ). En parlant de question, une petite en passant : pourquoi avoir choisi les macros ms, alors que mm paraît aussi complet, si ce n'est plus, à parcourir leurs manuels respectifs ? :)
        • [^] # Re: Syntaxe

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

          En fait, moi aussi je préfère utiliser \fB...\fP. Le problème survient lorsque plusieurs commandent commençant par \ s'enchaînent, comme c'est le cas dans la macro CROIX qui sert d'exemple ci-dessus: c'est illisible.

          Quant à la macro ms, je l'ai d'abord choisie ici parce qu'est c'est celle que j'utilise. Et je l'utilise parce que lorsque j'ai commencé à étudier groff, il m'a semblé que c'était la macro la plus simple pour commencer - et finalement, je n'en ai pas essayé d'autres.

          Il y a une raison plus générale qui motive le choix de la macro ms: cette macro est réputée être celle qui est le plus facilement modifiable. J'ai vu cela écrit quelques fois dans la liste de diffusion de groff, je sais que Peter Schaffter, le créateur de la macro mom s'est inspiré de cette macro, et c'est aussi l'exemple qu'utilisent Dale Rougherty et Tim O'Reilly dans Unix Text Processing.

          Comme, à mon avis, la puissance de *roff se dévoile lorsque l'on est en mesure d'écrire ses propres macros, chose qui ne devrait pas être insurmontable pour le public de dlfp, le choix de ms s'imposait d'une certaine façon.

          Pour un public moins averti, j'aurais probablement choisi mom comme exemple. Ce sera peut-être pour une prochaine fois...
          • [^] # [HS] De l'art de sortir une phrase de son contexte

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

            "pour le public de dlfp, le choix de ms s'imposait d'une certaine façon."

            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

          • [^] # Re: Syntaxe

            Posté par  . Évalué à 1.

            Quant à la macro ms, je l'ai d'abord choisie ici parce qu'est c'est celle que j'utilise. Et je l'utilise parce que lorsque j'ai commencé à étudier groff, il m'a semblé que c'était la macro la plus simple pour commencer - et finalement, je n'en ai pas essayé d'autres.

            Effectivement, ça cadre avec ce qui ressort des quelques bribes d'infos qu'on trouve à ce sujet sur le net ; à savoir que ms est moins puissant que mm, mais qu'il demeure suffisant dans la plupart des cas et est plus facile à apprendre. Merci pour ces précisions. :)
    • [^] # Re: Syntaxe

      Posté par  . Évalué à 2.

      Tiens? En lisant les docs j'avais tendance à préférer la syntaxe de lout à celle de LaTeX contrairement à toi, après je n'ai utiliser ni l'un ni l'autre..
      • [^] # Re: Syntaxe

        Posté par  . Évalué à 4.

        @BeginSections
        @Section @Title {Voici un titre}
        @Begin

        @PP
        Le contenu de la section.

        @End @Section
        @EndSections

        J'aime pas le @ qui est lourd visuellement.
        J'aime pas avoir à fermer mes sections, là en plus il me faut deux annotations pour le faire.

        Le même en LaTeX :
        \section{Voici un titre}
        Le contenu de la section.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Syntaxe

          Posté par  . Évalué à 1.

          Oui, à part l'encombrement du disque, je ne vois guère ce qui plaide en faveur de Lout au regard de LaTeX : la syntaxe est au moins aussi verbeuse, le maintien du processeur nettement plus incertain, et les performances de ce que j'ai vu très moyennes (chez moi la compilation du manuel d'utilisation, bourrée de références croisées, prend des plombes et harasse le CPU, qui pour sa part titre quand même à 2.66Ghz)...

Suivre le flux des commentaires

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