Journal Troff, l'enthousiasme

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
35
13
août
2014

Ce journal est juste un petit journal marque-page marqué par l'enthousiasme : La communauté Troff est prise d'un sursaut d'énergie qui redonne vie à l'ancestral logiciel.

Groff

Werner Lemberg, le mainteneur de Groff annonçait sa démission il y a quelques mois. Piquée au vif, la communauté d'utilisateurs s'est réveillée, à beaucoup discuté de l'avenir de son logiciel, et est en train de sortir de l'impasse : Non seulement Werner Lemberg est toujours présent et actif, mais en outre, Vaibhaw Pandey étudie actuellement les sources de Groff afin d'assurer à terme la tâche de mainteneur officiel.

Cerise sur le gâteau, Bertrand Garrigues a récemment posté un énorme patch, attendu depuis longtemps, permettant de compiler Groff avec automake. Ceci motive la sortie prochaine d'une nouvelle version de Groff afin d'avoir une base saine avant l'incorporation officielle de ce nouveau système de compilation.

Neatroff

Ali Gholami Rudi avait annoncé il y a environ un an la création de Neatroff, une implémentation de Troff adaptée aux graphies orientales et aux textes s'écrivant de droite à gauche. Son initiative était tellement personnelle - il utilise sa propre libc - qu'elle n'avait pas vraiment convaincu. Mais il annonce maintenant que Neatroff implémente des algorithmes de typographie de détail : le formatage paragraphe par paragraphe plutôt que ligne par ligne, ainsi que la gestion des extensions typographiques des polices TrueType et OpenType.

Au final, il nous propose une version de Troff aux fonctionnalités modernes et étendues, et au code source très épuré.

DWB Troff

L'unix d'AT&T de la fin des années 80 incorporait une version de Troff nommée DWB (Direct WorkBench) héritée de Kernighan. C'est cette version qui est à l'origine des Troff de Solaris et de Plan9. Carsten Kunze a décidé de sortir cette version de l'oubli, et l'a patchée pour lui permettre de compiler sur nos Posix d'aujourd'hui. Il entreprend d'en corriger les bugs, et puisqu'à quelques détails près cette version est semblable au Troff de Plan9, ses patchs contribueront directement au Troff de Plan9 !

Utroff

Quant à mon petit enfant, Utroff, il dormait tranquillement le temps que je soutienne ma thèse. Maintenant que c'est fait, il dort tranquillement le temps que je trouve un boulot… Autant dire que ce n'est pas demain qu'il se réveillera, car vu comment les choses s'annoncent, il est possible que je meurs de faim avant.

Post-Scriptum

Voilà donc un journal marqué par l'enthousiasme !

  • # cool

    Posté par  . Évalué à 2. Dernière modification le 13 août 2014 à 15:57.

    Cool, ca sert à quoi ? dans l'informatique moderne.

    Si je lis http://www.gnu.org/software/groff/

    typesetting system that reads plain text mixed with formatting commands and produces formatted output.

    Ok, comme le html, docbook ou markdown

    Output may be PostScript or PDF, html

    Ok, comme le html, docbook ou markdown

    Formatting commands may be either low-level typesetting requests

    Users may also write their own macros.

    Oula,

    Ca ressemble à TexInfo http://fr.wikipedia.org/wiki/Texinfo d'ailleurs, certains dans le monde emacs demandent la suppression de texinfo pour le remplacer par du html

    sophisticated documents while consuming only minimal system resources
    comme un subset d'html en somme.

    On peut générer des tableaux ?

    N'aurait-il pas mieux valu que tout cela meurt de sa belle mort ?

    • [^] # Re: cool

      Posté par  . Évalué à 5.

      Ca sert plutôt pour créer tes man pages par exemple.

      • [^] # Re: cool

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

        Après, pour ceux qui ne veulent pas apprendre le troff, c'est à dire à peu près tout le monde, il est tout à fait possible, et tout à fait pertinent, de rédiger ses pages de manuel en DocBook, ou encore en Markdown — mais c'est moins bien, DocBook disposant de toute une sémantique pour cela, par exemple pour préciser des options de commandes — et de les convertir avec une feuille de style XSL ou avec pandoc.

    • [^] # Re: cool

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

      Ok, comme le html, docbook ou markdown

      Non. Troff c'est comme Tex.

      • [^] # Re: cool

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 13 août 2014 à 16:20.

        En moins lié au formatage physique. TeX permet surtout de produire des trucs comme DVI, PS et PDF, très liés au format imprimé sur des pages de papier. Troff permet de produire du HTML. TeX aussi me direz-vous, avec des moteurs particuliers, mais ça reste un usage non prévu à la base et peu naturel.

        Je comparerais plutôt Troff à DocBook. Ou à Markdown, parce que pour le coup, la comparaison me semble pertinente. En moins riche et moins lisible, mais plus léger que DocBook, et en beaucoup plus riche que Markdown.

        • [^] # Re: cool

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

          TeX permet surtout de produire des trucs comme DVI, PS et PDF, très liés au format imprimé sur des pages de papier. Troff permet de produire du HTML.

          Euh, non. Troff a deux familles d'usage: les formats imprimés (surtout le postscript) et l'affichage sur terminal.

          On peut rediriger l'affichage sur terminal pour produire des fichiers textes et par extension du html ou du markdown, mais ce n'est pas vraiment son cœur de métier. À titre d'exemple, ce journal a été convertit avec Troff:

          nroff -muw j.tr > j.mkd

        • [^] # Re: cool

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

          En moins lié au formatage physique. TeX permet surtout de produire des trucs comme DVI, PS et PDF, très liés au format imprimé sur des pages de papier. Troff permet de produire du HTML.

          Plutôt pas d'accord: certaines personnes préfèrent utiliser groff pour écrire des maths aujourd'hui plutôt que TeX, car le premier leur donne un bien meilleur contrôle sur le placement des symboles dans les équations: la réalisation d'une typographie soignée proche du papier est une fonction importante de groff.

          • [^] # Re: cool

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

            certaines personnes préfèrent utiliser groff pour écrire des maths aujourd'hui plutôt que TeX, car le premier leur donne un bien meilleur contrôle sur le placement des symboles dans les équations

            C'est bien la première fois que je lis ça… J'ai plutôt l'habitude de lire que les mathématiciens préfèrent tant le rendu que la syntaxe de Tex, qui leurs sont plus familiers. Les deux ne sont pas antinomiques, certes…

            • [^] # Re: cool

              Posté par  . Évalué à 1.

              En ce qui me concerne, si j'utilise LaTeX c'est surtout parce qu'il y a plus de packages, en particulier pour le dessin (comme tikz), pas à cause de différences typographiques ni de syntaxe (c'est même le contraire : écrire du TeX en brut ne me plaît pas du tout).

            • [^] # Re: cool

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

              Les deux ne sont pas antinomiques, certes…

              Le but de mon exemple est de démontrer que troff est très près du rendu physique contrairement à ce qu'écrit Tanguy.

    • [^] # Re: cool

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

      Ok, comme le html, docbook ou markdown

      Tout faux. Ce que tu cites sont des langages décrivant des structures de document: on décrit un document par sa sémantique. Alors que groff est un langage décrivant l'aspect d'un document, c'est le genre de choses qu'il faut coller au bout de docbook pour obtenir un vrai document qu'on peut lire.

      Bien-sûr, comme pour TeX, comme groff est programmable on peut l'utiliser à travers des macros permettant une description sémantique du texte. Mais il ne fait pas se tromper, groff et TeX sont des machines à écrire de luxe.

      Et TeX et groff ont toutes les raisons du monde d'exister parceque pour réaliser des documents à la typographie compliquée, html, docbook et markdown sont complètement inutiles. Sans compter les mégaoctets de documents qu'ils permettent de préparer.

      • [^] # Re: cool

        Posté par  . Évalué à 1.

        moi, je veux bien mais de quoi on parle quand on dit "typographie compliquée" ? si tu veux bien m'expliquer, j'en serais fort aise.
        Parce que les pages man n'utilisent pas de mise en page très compliquée.

        Sans compter les mégaoctets de documents qu'ils permettent de préparer.

        je n'ai pas compris :-(

        Et TeX et groff ont toutes les raisons du monde d'exister

        Chacun est libre d'utiliser ce qu'il veut :-) Mais TeX, j'ai toujours trouvé ça très pénible pour faire des mises en pages complexes et personnalisée. C'est par contre parfait pour des thèses.

        • [^] # Re: cool

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

          moi, je veux bien mais de quoi on parle quand on dit "typographie compliquée" ?

          Et bien en gros, il s'agit des tableaux et des équations. Ce type de préparation est très difficile à généraliser, à preuve la complexité des packages des macros pour la préparation de tableaux disponibles pour LaTeX.

          Par exemple, dans ces deux types de préparation, il est courant de placer des gabarits pour corriger les alignements, d'utiliser des élément invisibles, de faire du kerning, etc. et toutes ces choses là sont difficiles ou impossible à faire avec HTML, Markdown ou DocBook, parceque ces descriptions sont très éloignées du support physique.

          Sans compter les mégaoctets de documents qu'ils permettent de préparer.

          je n'ai pas compris :-(

          Il existe des mégaoctets de documents pour TeX et troff, deux excellentes raisons pour continuer de mettre à jour ces logiciels.

          % env BLOCKSIZE=k du -s /usr/local/man/man* /usr/share/man/man* | awk '{t+=$1}END{print(t)}'
54472

          Sur ma machine il y a 54 Mo de pages de man, comme elles sont compressées on est assez proches de la quantité d'information. Pour TeX en regardant ce qui est publié chaque jour sur arXiv.org, vu qu'un article typique fait plus de 150ko comprimé, on peut dire que la quantité de documents écrits en TeX croit de plusieurs Mo tous les jours.

          Mais TeX, j'ai toujours trouvé ça très pénible pour faire des mises en pages complexes et personnalisée.

          Quelque soit le logiciel utilisé, c'est très difficile de réaliser des mises en pages complexes et personnalisées — qui soient réussies, s'entend — et typographe ou graphic designer sont des métiers. Avec TeX on est bien obligé de laisser ça à des professionnels, avec un WYSISWYG classique on obtient invariablement un résultat attendrissant comme un collier de nouilles colorées pour la fête des mères.

          • [^] # Re: cool

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

            toutes ces choses là sont difficiles ou impossible à faire avec HTML, Markdown ou DocBook, parceque ces descriptions sont très éloignées du support physique

            Oui pour Markdown et DocBook mais en HTML, tu peux mélanger du fond et de la forme comme en TeX. Idem, en TeX (LaTeX), tu peux faire un document très propre sans forme. C'est d'ailleurs très souvent le cas…

            • [^] # Re: cool

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

              Oui pour Markdown et DocBook mais en HTML, tu peux mélanger du fond et de la forme comme en TeX.

              Tu peux, mais l'évolution de la norme est plutôt de supprimer tous les attributs de style explicites du HTML pour les déplacer dans CSS et j'ai la flemme de vérifier mais tous les attributs de style explicite dans HTML sont probablement obsolètes (deprecated).

              De plus les attributs de style ne sont pas contraignants (autrement dit, c'est de la décoration), ce qui fait une légère différence avec TeX et troff, pour lesquels au contraire ces attributs sont cruciaux.

              Idem, en TeX (LaTeX), tu peux faire un document très propre sans forme. C'est d'ailleurs très souvent le cas…

              Apparemment tu ne suis pas trop la discussion, là on parle justement du cas où ce n'est pas possible.

              • [^] # Re: cool

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

                Je suit justement la discution et je confirme que à ce jour, on ne peux pas mettre HTML d'un coté et TeX de l'autre… En plus, ton argument les attributs de style ne sont pas contraignants est pipeau. En TeX aussi ton style peux faire ce qu'il veut !

                Bref, en HTML, tu as l'attribut style pour chaque balise et en plus, tu as maintenant la balise style. Cf http://www.w3ctutorial.com/html5-tags/tag-style

                Bref, le CSS est intégré dans le HTML et complètement fusionné via cette balise.

                Donc pour moi, HTML est vraiment du même coté que TROFF ou TeX.

                Par ailleurs, il n'est pas inutile de dire qu'en TeX, on peux faire des documents n'ayant aucun élément de style car avec ce genre de discution, on finit par faire croire au gens que cela n'est pas possible et qu'il faut forcément des syntaxes wiki…

                • [^] # Re: cool

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

                  Je suit justement la discution

                  On ne dirait pas. Nous on parle des cas de typographie compliquée

                  moi, je veux bien mais de quoi on parle quand on dit "typographie compliquée" ?

                  Et bien en gros, il s'agit des tableaux et des équations.

                  Et toi tu viens nous parler des cas de typographie simple (là où, en gros, il n'y en a pas):

                  Idem, en TeX (LaTeX), tu peux faire un document très propre sans forme. C'est
                  d'ailleurs très souvent le cas…

                  J'en ai parlé à mon livreur de pizza, il pense aussi que tu es à côté de la plaque.

                  Bref, le CSS est intégré dans le HTML et complètement fusionné via cette balise.

                  CSS et HTML sont deux “normes” distinctes.

                  Donc pour moi, HTML est vraiment du même coté que TROFF ou TeX.

                  À mon avis, tu devrais recompter le nombre de fois qu'il y a écrit may dans la norme de CSS!

                • [^] # Re: cool

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

                  Je suis plutôt d'accord avec Sytoka Modon sur le fait que le html/css peut être compris comme un langage de formatage de textes à l'image des langages Troff et Tex.

                  Par contre, au niveau de moteurs de rendus, entre les navigateurs et les logiciels Troff et Tex, il y a, à mon avis, une différence nette:

                  • l'interprétation des langages Troff et Tex est stricte (même code, même rendu), l'interprétation du langage html/css ne l'est pas.
                  • Du point de vue de la qualité du rendu typographique, le navigateur est bon dernier: les césures sont le b-a-ba de la typographie, et apparemment le navigateur ne sait pas les créer. Et il en va de même des autres techniques typographiques: ligatures, réglage de l'approche, contraintes sur l'espace inter-mots, gris typographique, gestion des veuves et des orphelines, etc. tout ça est du chinois pour le navigateur.

                  • [^] # Re: cool

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

                    Les moteurs de rendus HTML sont loin d'être à la hauteur sur certains détails mais c'est une autre histoire ;-) De plus, pour TROFF et TeX, il y a clairement un moteur 'officiel'. Ceci dis, comme pour le HTML, à ma connaissance, rien n'est écrit noir sur blanc !

                    • [^] # Re: cool

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

                      pour TROFF et TeX, il y a clairement un moteur 'officiel'.

                      Pour Troff, il n'y a clairement pas de moteur officiel. Le Troff de Kernighan (du moins ce qu'il nous en reste) a quelques bugs. Groff, n'a pas ces bugs, mais son rendu est régulièrement mis à l'épreuve de documents justement formatés par le Troff de Kernighan. On tournerait dans un cercle vicieux s'il n'y avait pas une norme qui sert de référence officielle pour tous les moteurs.

                      Et entre PdfTex et le Tex de Knuth, lequel est le moteur officiel ?

                    • [^] # Re: cool

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

                      Les moteurs de rendus HTML sont loin d'être à la hauteur sur certains détails mais c'est une autre histoire ;-)

                      Si on parle de typographie fine, c'est assez loin d'être une autre histoire.

                      Ceci dis, comme pour le HTML, à ma connaissance, rien n'est écrit noir sur blanc!

                      Tous les algorithmes de TeX sont soigneusement documentés et il y a même des implémentations alternatives en OCaml ou Java (ou du moins des projets pour le faire, mais vu que ça ne sert à rien, ce genre de chose s'arrête tout seul).

                  • [^] # Re: cool

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

                    Je suis plutôt d'accord avec Sytoka Modon sur le fait que le html/css peut être compris comme un langage de formatage de textes à l'image des langages Troff et Tex.

                    Ce n'est pas la question, on parle de typographie fine…

                    l'interprétation des langages Troff et Tex est stricte (même code, même rendu),
                    l'interprétation du langage html/css ne l'est pas.

                    donc exit html/css pour la typographie fine.

                    Ce n'est pas que ce que vous dites est faux ou inintéressant, c'est juste HS.

                    • [^] # Re: cool

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

                      Ce n'est pas la question, on parle de typographie fine…

                      Ben oui, mais lui il veut parler de typographie grasse, alors bon…

                  • [^] # Re: cool

                    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 14 août 2014 à 22:56.

                    Du point de vue de la qualité du rendu typographique, le navigateur est bon dernier: les césures sont le b-a-ba de la typographie, et apparemment le navigateur ne sait pas les créer. Et il en va de même des autres techniques typographiques: ligatures, réglage de l'approche, contraintes sur l'espace inter-mots, gris typographique, gestion des veuves et des orphelines, etc. tout ça est du chinois pour le navigateur.

                    Ben, pas tout à fait…

                    • Césures : en CSS il y a "hyphens : auto;" mais souvent mieux rendues par "-ms-hyphens : auto;" et -moz-hyphens : auto;". J'ai les ai depuis belle lurette dans mes blogs. Ça marche avec IE ou Firefox mais pas avec Chromium.
                    • ligatures : ça existe aussi en HTML car ça existe en Unicode.
                    • Les veuves et orphelins : c'était déjà dans la norme CSS2-1 … Voir à Orphans et Widows
                    • Les espaces inter-mots : ça existe aussi en CSS, par exemple "text-justify : inter-word;".

                    Certes, le triplet HTML + CSS + SVG n'est peut-être pas aussi pointu que peuvent l'être (La)TeX/PStricks ; mais ces trois normes sont, en l'état actuel, largement sous exploitées.

                    De toute façon, je rejoins celui qui a dit plus haut que la typo c'était un vrai métier. Que l'on code en HTML, en TeX ou en TGroff ça nécessite les même connaissances de base qu'avaient ceux qui scriptaient à la main les bouquins avant Gutemberg puis les imprimeurs au plomb. Pour les gens de notre siècle, hors la lecture des milliers de pages des normes, point de salut. Amen.

                    • [^] # Re: cool

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

                      le triplet HTML + CSS + SVG n'est peut-être pas aussi pointu que peuvent l'être (La)TeX/PStricks

                      A mon avis, le problème n'est pas la. Tu transformes ton HTML en TeX puis le moulines avec TeX et ton rendu est impeccable. Donc on sais faire du rendu HTML impeccable ;-)

                      Si tu veux faire une simulation mécanique en grande transformation, il te faut un code qui va mouliner des heures et des heures sur un cluster, si tu veux faire la même genre de chose dans un jeu, tu prends des équations simplifiées qui visuellement donne un truc pas trop mal. Idem avec les cartes graphiques, les cartes pro ne doivent pas forcément aller plus vite mais le résultat doit être toujours juste alors qu'une carte de gamer peut avoir un pixel qui déconne de temps en temps dans l'affichage du moment que le jeu ne lag pas.

                      Bref, on a deux types de moteurs : un moteur dédié rendu papier, imprimeur professionnel, et un moteur dédié temps réel, rendu écran. Les moteurs de rendus des navigateurs sont obligés de prendre des modèles simplifiés…

                      Bref, pour moi, la qualité du résultat n'est pas forcément lié à une question de langage de description mais bien à la problématique visée.

                      • [^] # Re: cool

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

                        La qualité du résultat n'est pas forcément lié à une question de langage de description mais bien à la problématique visée.

                        Je suis assez d'accord, d'autant plus que les langages ne sont au final que des étapes dans l'immense conversion d'un langage à un autre qui constitue l'informatique.

                        Langage man > langage Troff > langage Ditroff > mangage PostScript > langage Pdf.
                        Langage LaTex > langage Tex > langage DVI > langage PostScript > langage Pdf.

                        Les moteurs de rendus des navigateurs sont obligés de prendre des modèles simplifiés…

                        Là, par contre, je tousse… C'est tout de même osé de dire que html+css et un modèle simple de description de page. Il y a des gens qui sont capables d'écrire des parseurs Tex ou Troff, mais personne n'est capable d'écrire un parseur html/css.

                        • [^] # Re: cool

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

                          C'est tout de même osé de dire que html+css et un modèle simple de description de page

                          Je parle des algo dans les moteurs de rendus HTML qui sont soumis à la problématique temps réel, non du langage de description ;-)

  • # Troff

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

    Troff, c'est bien ce format de rédaction de documents, utilisé essentiellement pour les pages de manuels, qui utilise un formatage physique direct plutôt que des styles logiques, et qu'on utilise essentiellement en cible de convertisseurs à partir de DocBook ou de Markdown ?

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 6. Dernière modification le 13 août 2014 à 16:38.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Troff

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

        Ce serait chouette en effet. Actuellement, on peut toujours rédiger une page de manuel en Markdown puis la convertir en troff avec Pandoc.

        En revanche, Markdown a un inconvénient majeur, c'est qu'il a des lacunes importantes (tables, blocs de code autrement qu'en préfixant toutes les lignes d'espaces, listes de définitions et notes), qui n'ont pas été corrigées mais qui ont conduit à la création de version étendues concurrentes.

        • [^] # Re: Troff

          Posté par  . Évalué à 2. Dernière modification le 13 août 2014 à 22:27.

          oui, markdown est horriblement limité, et ses créateurs l'ont rapidement laissé en plan une fois l'avoir « inventé », si bien ce que l'on a eu ces versions « améliorées » et incompatibles entre elles. Pourtant une solution existait au lieu de faire un fork complet de markdown à chaque fois ("markdown extra", "markdown linuxfr", "markdown github"), cela aurait été d'indiquer dans l'entête d'un document donnés les modifications apportées à la syntaxe de base, forcément restreinte en possibilité. C'est bête personne n'y a pensé.

          C'est d'ailleurs ce que permet d'origine txt2tags, et cela plusieurs années avant l'invention de markdown :

          https://github.com/farvardin/whatistxt2tags

          Voir en particulier la partie « Markdown support », qui rajoute une grosse partie de la syntaxe markdown à txt2tags, pour ceux qui auraient leurs habitudes, et qui donne un avant-goût des possibilités d'extension du système.

          Le rajout markdown est rendu possible grâce à ces regex :

          %!preproc: '^# (.*?)$' '= \1 ='
%!preproc: '^## (.*?)$' '== \1 =='
%!preproc: '^### (.*?)$' '=== \1 ==='
%!preproc: '^#### (.*?)$' '==== \1 ===='
%!preproc: '^##### (.*?)$' '===== \1 ====='
%!preproc: '^\* (.*?)$' '- \1'
%!preproc: '^(\d+)\. (.*?)$' '+ \2'
%!preproc: '\[(.*?)\]\(\http://([^ ].*?)\)' '[\1 http://\2]'
%!preproc: '^>' '\t'
%!postvoodoo: '(.*?)\n=[=*]{2,}=' '<h1>\1</h1>'
%!preproc: '-[-*]{18,}-' 'T2TBAR'
%!preproc: '-[-*]{2,}' 'MDUNDERLINE'
%!postproc: 'MDUNDERLINE' '------'
%!postproc: 'T2TBAR' '<hr/>'
%!postvoodoo: '(.*?)\n-[-*]{2,}-' '<h2>\1</h2>'

          C'est simple, efficace, direct et ça reste encore extensible.

          D'ailleurs il y a des choses pas mal en markdown : ## titre au lieu de == titre == c'est peut-être un peu plus joli aux yeux de certains, le > pour les citations c'est mieux qu'une tabulation peu pratique à écrire dans un formulaire web, les * c'est plus visible que - pour une liste, bref, avec ce système de regex ça permet de se constituer sa propre syntaxe perso et ça reste toujours lisible et interprétable par le convertisseur txt2tags d'origine (que cela soit en version python ou en php, l'interpréteur javascript étant encore limité)

          (ps : txt2tags peut également exporter en pages de man et en utroff)

          « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

          • [^] # Re: Troff

            Posté par  . Évalué à 2.

            sympa txt2tags, j'étais resté sur ReStructuredText qui est dans le même genre mais galère pour les tableaux notamment l'insertion d'image dans un tableau ou des cellules multi-lines.

            Après le gros soucis de ce genre d'outil, c'est que les coupures de pages sont très moches, et que parfois, on peut se retourver avec une page et 2 lignes de texte.

            • [^] # Re: Troff

              Posté par  . Évalué à 1.

              Si c'est pour convertir en LaTeX, après ça dépend de ce qu'on a mis dans le style, mais normalement ça se passe plutôt bien.

              « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

            • [^] # Re: Troff

              Posté par  . Évalué à 3.

              sphinx est à ReStructuredText ce que LaTeX est à TeX : absolument indispensable :-)

          • [^] # Re: Troff

            Posté par  . Évalué à 3.

            Je ne connaissais pas et je je trouve très bien que ça existe dans txt2tags car il y a un public pour ça.

            Ceci dit, je n'aimerais pas voir cette solution s'imposer dans le monde markdown.

            En effet, ça ne ferait qu'empirer la profusion de syntaxes markdown-like.
            Compatibles entre elles ? D'un point de vue technique oui
            Mais les syntaxes seraient incompatibles entre elles du point de vue de celui qui écrit qui à chaque fois qu'il utilise un site différent ou un logiciel différent aurait à se demander dans quelle mesure la syntaxe a été customisée, lire une page de manuel ou des instructions de processing, configurer les instructions auxquelles il est habituée, synchroniser ses configurations s'il prend l'habitude d'étendre la syntaxe, …
            Et on se retrouverait pour résoudre des problèmes secondaires de la syntaxe markdown à perdre de vue son atout essentiel qui est sa simplicité.

            Je préfère qu'un petit comité de gens intelligents définisse un markdown 2.0 qui définisse un sur-ensemble de markdown raisonnable (sur la base de e qui existe déjà), tout en étant nécessairement limité pour garder toujours en tête cette objectif de préserver la simplicité initiale de markdown.

            • [^] # Re: Troff

              Posté par  . Évalué à 1.

              Je préfère qu'un petit comité de gens intelligents définisse un markdown 2.0 qui définisse un sur-ensemble de markdown raisonnable

              oui mais on sait bien que cela n'existera jamais…

              Entre celui qui ne voudra que publier sur le web, l'autre qui voudra publier du code et des formules mathématiques, et le dernier qui voudra publier du PDF avec références bibliographiques, notes de fin de chapitres, exergues etc (cas de Pandoc qui utilise une syntaxe modifiée et étendue)…

              Titre de l'image

              « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

              • [^] # Re: Troff

                Posté par  . Évalué à -1.

                Someone is wrong on the internet

                Quitte à citer xkcd je préfère cette vignette là.

        • [^] # Re: Troff

          Posté par  . Évalué à 5.

          En revanche, Markdown a un inconvénient majeur, c'est qu'il a des lacunes importantes (tables, blocs de code autrement qu'en préfixant toutes les lignes d'espaces, listes de définitions et notes), qui n'ont pas été corrigées mais qui ont conduit à la création de version étendues concurrentes.

          C'est pire que ça : markdown ne permet pas de faire la différence entre une option en ligne de commande, entre un nom de fichier et un nom de variable, un #include, etc… on est limité à trois catégories sémantiques code, important et très important, dans lesquelles on doit tout ranger, et si on décide de ranger deux choses dans la même, c'est impossible de changer d'avis par la suite. Mais aussi, impossible dans ces conditions de faire un programme apropos qui permette de faire des recherches sémantiques pour savoir quelles pages man parlent d'un certain fichier, quelles pages man utilisent tel #include, où est-ce que telle variable d'environnement est décrite etc. et on est réduit à chercher à coup de regexps ce qui est moins pratique, donne de moins bons résultats, et ne permet pas d'indexer dans une base de données pour avoir des réponses rapides.

    • [^] # Re: Troff

      Posté par  . Évalué à 10.

      La victime toute désignée à un futur manpaged

    • [^] # Re: Troff

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

      D'après ce que je comprend de la page GNU.
      J'assimilerais plutôt ce logiciel comme un analyseur lexical qui permet de passer d'une grammaire A vers une autre B en fonction des règles qu'on lui a donné.
      Si je ne plante pas dans ma compréhension, ce genre d'outils est très utile pour de nombreuses action, principalement pour les gens qui travaillent sur les langages formels.

      utilisé essentiellement pour les pages de manuels

      J'ai fait l'essai le plus simple du monde :

      groff >test
azerty
<CTRL+D>

      Et il m'a généré un PDF.
      Donc son usage a sûrement un peut évolué.

      kentoc'h mervel eget bezan saotred

    • [^] # Re: Troff

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 13 août 2014 à 18:11.

      utilisé essentiellement pour les pages de manuels, qui utilise un formatage physique direct plutôt que des styles logiques

      Les pages de manuel écrites avec groff_mdoc(7) utilisent des styles logiques, et c'est la grosse majorité des pages de manuel.

    • [^] # Re: Troff

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

      utilise un formatage physique direct plutôt que des styles logiques

      Le langage est un langage de formatage de texte, et à ce titre il opère un formatage physique.

      Par contre, avec ce langage, on créé des macros, qui elles, peuvent être sémantiques. Mdoc et utmac en sont des exemples.

  • # troff | less

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 13 août 2014 à 17:13.

    Puisqu'on parle de Troff, j'en profite pour vous faire part d'un truc que j'ai découvert récemment. Quand on demande une page de manuel, celle-ci s'affiche dans un pageur tel que less (ou more, ou most…), et certains titres ou mots apparaissent en gras ou en souligné. D'où cette interrogation : comment pageur qui est censé lire du texte brut, peut-il identifier et afficher ces subtilités ?

    On trouve la réponse en passant par un pseudo-pageur qui écrit en fait dans un fichier : le gras est obtenu en faisant suivre chaque lettre par un retour arrière puis un second exemplaire d'elle-même, et le soulignement en faisant suivre chaque lettre par un retour arrière puis un tiret bas ! En rédigeant à la main ce genre de texte, par exemple avec Vim (^V puis retour arrière pour insérer un caractère retour arrière), on obtient un rendu gras ou souligné avec un pageur.

    • [^] # Re: troff | less

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

      Comme une machine à écrire quoi. Ou une ancienne imprimante comme au début d'UNIX.

    • [^] # Re: troff | less

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

      le gras est obtenu en faisant suivre chaque lettre par un retour arrière puis un second exemplaire d'elle-même, et le soulignement en faisant suivre chaque lettre par un retour arrière puis un tiret bas

      En fait c'est beaucoup plus riche que ça, puisque les codes de contrôle ANSI sont utilisés par certaines version pour obtenir des vraies italiques ou des couleurs (le support dépend bien-sûr du terminal). Je ne sais pas comment le faire, mais je l'ai déjà vu, promis, juré.

      On peut demander à less d'interpréter différemment ces codes de contrôle, je recopie la documentation des options -r et -R (à afficher en cinémascope ☺):

      -r or --raw-control-chars
       Causes "raw" control characters to be displayed.  The default is
       to  display  control  characters  using  the caret notation; for
       example, a control-A (octal 001) is displayed as "^A".  Warning:
       when the -r option is used, less cannot keep track of the actual
       appearance of the screen (since this depends on how  the  screen
       responds to each type of control character).  Thus, various dis-
       play problems may result, such as long lines being split in  the
       wrong place.

-R or --RAW-CONTROL-CHARS
       Like  -r,  but  only ANSI "color" escape sequences are output in
       "raw" form.  Unlike -r, the screen appearance is maintained cor-
       rectly  in  most  cases.   ANSI  "color"  escape  sequences  are
       sequences of the form:

            ESC [ ... m

       where the "..." is zero or more color  specification  characters
       For  the  purpose  of  keeping  track of screen appearance, ANSI
       color escape sequences are assumed to not move the cursor.   You
       can  make less think that characters other than "m" can end ANSI
       color escape  sequences  by  setting  the  environment  variable
       LESSANSIENDCHARS to the list of characters which can end a color
       escape sequence.  And you can make less  think  that  characters
       other  than the standard ones may appear between the ESC and the
       m by setting the environment variable  LESSANSIMIDCHARS  to  the

      • [^] # Re: troff | less

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

        En fait c'est beaucoup plus riche que ça, puisque les codes de contrôle ANSI sont utilisés par certaines version pour obtenir des vraies italiques ou des couleurs (le support dépend bien-sûr du terminal). Je ne sais pas comment le faire, mais je l'ai déjà vu, promis, juré.

        Moi je sais et je l'ai déjà fait. Mais ce n'est pas ce qui est utilisé quand on appelle man, et vous pouvez le vérifier en affichant la liste des processus en cours d'exécution alors que vous affichez une page de manuel : le pageur est appelé sans options. Enfin, sans -r ou -R en tout cas.

        • [^] # Re: troff | less

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

          La variable d'environnement $PAGER permet d'ajouter ces options. Il existe aussi la variable $MANPAGER si besoin.

          • [^] # Re: troff | less

            Posté par  . Évalué à 2.

            On peut aussi garder PAGER="less", et mettre les options dans la variable LESS (par exemple : LESS="-R").

            Pour les couleurs, il y a les variables LESS_TERMCAP_*, pour ma part je m'étais contenté de pomper un exemple sur le net, pour avoir des manpages en couleur :
            export LESS_TERMCAP_mb=$'\E[01;37m'
            export LESS_TERMCAP_md=$'\E[01;37m'
            export LESS_TERMCAP_me=$'\E[0m'
            export LESS_TERMCAP_so=$'\E[40;36m'
            export LESS_TERMCAP_se=$'\E[0m'
            export LESS_TERMCAP_us=$'\E[36m'
            export LESS_TERMCAP_ue=$'\E[0m'

        • [^] # Re: troff | less

          Posté par  . Évalué à 1.

          Sur hp-ux, c'est pas toujours aussi simple :
          L'appel à man test donne :

          0:00 sh -c cd /usr/man; tbl -TX /tmp/man008760 | neqn | nroff -man | col -x | more -s

  • # troff

    Posté par  . Évalué à 10.

    Ils sont trofforts ces développeurs.

    • [^] # Re: troff

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

      Alenvers<, sort de ce corps !

      • [^] # Re: troff

        Posté par  . Évalué à 4.

        Pour une fois ce n'est pas une catastroff tous ces calembours…

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

        • [^] # Re: troff

          Posté par  . Évalué à 1. Dernière modification le 16 août 2014 à 19:25.

          Il faut pas qu'tu TeXites ;-)

  • # thèse

    Posté par  . Évalué à 2.

    Quant à mon petit enfant, Utroff, il dormait tranquillement le temps que je soutienne ma thèse.

    elle est libre la thèse ? Je serais curieux de voir ce que utroff donne sur un projet d'envergure (bon, il y a quand même le manuel pour se rendre compte…)

    il est possible que je meurs de faim avant.

    c'est pas évident de trouver du boulot quand on a un doctorat de philo ? Quels débouchés existent ? Ou alors tu cherches dans l'informatique ?

    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

    • [^] # Re: thèse

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

      Ah, enfin quelqu'un qui suit…

      elle est libre la thèse ?

      Non, elle n'est pas libre, ni même publiée en ligne. Il y a des choses que j'ai envie de modifier avant de penser à une publication. Et une fois ces modifications faites, il est probable que je tente d'abord ma chance chez un éditeur.

      J'envisage d'éditer un texte libre pour servir d'exemple des macros d'Utroff, mais ce n'est pas encore fait.

      c'est pas évident de trouver du boulot quand on a un doctorat de philo ? Quels débouchés existent ? Ou alors tu cherches dans l'informatique ?

      Ce n'est pas évident, non. Le débouché par défaut est l'enseignement au lycée, mais il y a embouteillage (et d'autres raisons qui font que j'aimerais éviter de passer par là).

      La philosophie est une vieille discipline, qui considère que la formation de l'esprit, l'exercice du jugement, l'habileté à manipuler des concepts, et l'exercice de la faculté d'apprendre sont les compétences les plus appréciables pour l'homme. Mais maintenant qu'il existe pour chaque emploi une formation ad-hoc, j'ai le défaut de n'avoir pas suivi la dite formation, et ma candidature passe loin derrière celle de personnes beaucoup moins diplômées que moi.

      Pour la première fois (après 98 candidatures), je postule en ce moment à un poste où je peux faire valoir ma pratique de la philosophie: il s'agit de coordonner les groupes de réflexion d'un milieu professionnel. Une perle rare.

      Ou alors tu cherches dans l'informatique ?

      Je n'ai pas les compétences pour être développeur ou administrateur. Peut être qu'il y a des emplois à la marge où mon profil littéraire et mon expérience de la programmation peuvent être des atouts, mais je ne connais pas assez ce milieu pour me rendre compte des besoins.

      • [^] # Re: thèse

        Posté par  . Évalué à 3.

        il s'agit de coordonner les groupes de réflexion d'un milieu professionnel

        ah, c'est modérateur sur linuxfr ? ;))

        blague à part, bon courage dans tes recherches en tout cas !

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

  • # Utiliser pour les mails ou les éditeurs de texte ?

    Posté par  . Évalué à 2.

    Bonjour,

    Tout est dans le titre. J’aime beaucoup le formatage des pages man, notamment la justification du texte et la césure automatique. Il y a bien un outil par, mais il est moins bon. Est-ce que quelqu’un a déjà essayé d’utiliser *roff pour :
    — formater des mails pour affichage (typiquement dans Mutt avec mailcap) ;
    — formater les paragraphes (typiquement la commande gq de Vim, qui peut créer un tube vers n’importe quelle commande via la variable formatprg) ?

    • [^] # Re: Utiliser pour les mails ou les éditeurs de texte ?

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

      Je sais que certains ont dit utiliser troff pour mettre en page leurs mails sur la liste de discussion de Groff. Ça vaut peut-être le coup d'aller y jeter un coup d'œil.

      Pour l'exemple:

      echo "
.de end
.pl \\n(nlu
..
.em end
.ll 50m
.hla fr
Lorem ipsum." | groff -T utf8

      Pour vim, je suis moins convaincu. J'aurais plutôt tendance à passer le document entier dans la moulinette groff plutôt que chacun de ses paragraphes.

      • [^] # Re: Utiliser pour les mails ou les éditeurs de texte ?

        Posté par  . Évalué à 2. Dernière modification le 18 août 2014 à 15:09.

        Ah merci ! En fait c’est exploitable en pipant le texte brut direct, mais ce qui me manquait le plus c’était le .ll pour la taille de la ligne, le .hla (en espérant que ça corrige les césures dégueulasses par défaut), et le .in que j’ai trouvé par moi-même, pour la marge gauche. Pour le reste je vais creuser tranquille pour perfectionner le tout, le nec plus ultra ce serait d’avoir un interpréteur complet supportant text/enriched et text/html. :)

        Pour Vim je préfère avoir le rendu dans l’éditeur, comme ça je peux apporter quelques menues corrections si besoin. C’est surtout pour des prises de notes que je prévois de m’en servir, c’est pas destiné à une visualisation à part.

        • [^] # Re: Utiliser pour les mails ou les éditeurs de texte ?

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

          Plutôt que .in, on utilise plutôt la commande .po (page offset), pour définir la marge par défaut. .in sert surtout à modifier temporairement l'offset.

          Bien réglée, les césures ne devraient pas poser de problèmes, mais j'utilise trop peu groff pour t'aider.

          Peut-être seras-tu intéressé par les commandes suivantes: .ad [l|b|r] (adjust left, both, right) pour l'alignement, .nf (no fill) qui supprime tout forme alignement (pour écrire du code par exemple), .fi (fill) qui ré-enclenche l'alignement.

          Et pour avoir un peu d'élan pour la suite, voilà une petite macro pour écrire des notes, imparfaite sur bien des points, mais simple:

          .nr x 0 1 \" numéro des notes
.de ns
.\" macro ns commence les notes
(\\n+x)
.   ev 1 \" ouvre un environnement dédié aux notes
.   br \" casse le flux
.   da print \" divertit le flux vers print
.   sp \" espace
\\nx)
..
.de ne
.\" macro ne ferme les notes
.   br \" casse le flux
.   di \" ferme la diversion
.   ev \" sort de l'environnement
..
.de end
.\" macro appellée à la fin du document
.   br
.   ev 1 \" en retourne dans l'environnement des notes
.   print \" execute le contenu de la diversion
.   br
.   ev
.   pl \\n(nlu \" ajuste la taille de la page au nombre de lignes
..
.\" définit la macro .end comme macro de fin de document:
.em end

Suivre le flux des commentaires

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