Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile

La bureautique est la principale utilisation de l’informatique depuis sa création. Pourtant, les outils majoritairement utilisés dans ce domaine, les logiciels de traitement de texte WYSIWYG comme LibreOffice et OpenOffice, laissent la majorité des informaticiens et des ergonomes très dubitatifs, voire totalement désespérés.

Ces logiciels ont en effet un nombre de défauts très important : ils font se concentrer sur la forme et non sur le fond, leur résultat final ne correspond souvent pas à ce qui est affiché, ils sont incompatibles entre eux, ce sont d’énormes usines à gaz inutilisables sur de vieilles machines, ils ne fonctionnent qu’en mode graphique, etc. La seule manière rationnelle, efficace et interopérable de travailler sur un ordinateur est d’utiliser de simples fichiers textes, tous les documents étant donc modifiable dans n’importe quel éditeur de texte.

Il a donc fallu penser à une manière de donner ces instructions de mise en forme au sein du fichier texte lui-même, et c’est ainsi que sont apparus les langages de balisage (markup), dont les plus connus sont HTML (inventé en 1991 par Tim Berners-Lee) et LaTeX (créé en 1985, et basé sur TeX, inventé par le grand Donald Knuth en 1977), et dont la première grande figure fut Roff, un programme Unix historique développé à partir de 1961, et dont la version GNU, Groff, est installée par défaut sur toutes les distributions Linux, puisqu’on l’utilise encore pour les pages de man des logiciels.

Pour mieux visualiser, prenons comme exemple la création d’une nouvelle section d’un document en man :

.SH Nouvelle section en man

en HTML :

<h1>Nouvelle section en HTML</h1>

et en LaTeX :

\section{Nouvelle section en LaTeX}

Ces langages représentent une nette amélioration, mais ont tous un gros problème : ils sont gênants ! On ne retrouve plus aussi facilement son contenu au milieu de toutes ces balises supplémentaires, sans parler du fait que les syntaxes complexes ouvrent la voie à de nombreuses erreurs de compilation.

C’est en 1995 que l’on trouva la solution de ce problème, avec la création du premier langage Wiki, dont le but principal était de permettre l’édition facile de pages web par tout un chacun, et dont l’utilisateur actuel le plus célèbre est l’encyclopédie libre Wikipédia. S’il y a presque autant de syntaxes différentes que de logiciels Wiki, elles ont toutes la caractéristique d’utiliser des caractères textuels simples et intuitifs pour donner les indications de formatage du texte.

Toujours le même exemple, une nouvelle section en MediaWiki :

= Nouvelle section Wiki =

et une en Setext :

Nouvelle section Setext
=======================

Mais pourquoi limiter ces langages de balisage léger à la seule génération de HTML ? Pourquoi ne pas utiliser la même syntaxe pour différentes cibles (appelées backends, targets ou writers selon les logiciels), de manière à obtenir aussi bien une page web en HTML, qu’un document en LaTeX pour l’impression, ou qu’une page de man pour un logiciel ? Ce sont les logiciels qui poursuivent ce but qui m’intéressent, ils constituent pour moi l’avenir de la bureautique informatique, et j’ai été amené à les comparer pour en choisir un dans lequel m’investir comme développeur.

Voici un tableau comparatif des meilleurs logiciels libres existants, avec comme information supplémentaire l’existence d’une cible texte brut, puisque je souhaitais me baser sur ce code pour programmer certaines de mes idées ASCII art.

Les logiciels complets MAJ

NomLangage de programmationPopularité du projeti18nCible texte brutLicence
Txt2tagsPythonmoyenne + RedNotebookOui + docOuiGNU GPLv2 ou suivante
DocutilsPythonforte + SphinxNonNonDomaine public
AsciiDocPythonforteNonDump de w3m ou de LynxGNU GPLv2 ou suivante
DeplateRubyfaibleNonOuiGNU GPLv2 ou suivante
PandocHaskellmoyenneNonOuiGNU GPLv2 ou suivante
Stx2anySed et m4faibleNonDump de w3mLicence copyleftée personnalisée
AFTPerlfaibleNonNonClarified Artistic License
LunamarkLuafaibleNonNonMIT
JeromeErlangfaibleNonNonMIT
DoxiaJavaforteNonNonApache License 2.0
XWiki RenderingJavafaibleNonOuiGNU LGPLv2.1

Exceptés Docutils et AFT (Almost Free Text), tous les logiciels semblaient au premier abord proposer une cible texte. Mais en fait c’est un peu un trompe l’œil, car deux d’entre eux, AsciiDoc et Stx2any, se contentent de dumper un navigateur web en mode texte (w3m ou Lynx) du résultat généré par leur cible HTML. Il n’y avait donc pas dans ces cas de base de code que je pouvais espérer améliorer.

J’ai mis dans le comparatif stx2any et AFT codés respectivement en m4 et en Perl, de manière à proposer un large éventail de langages de programmation, mais ces logiciels sont à la fois moins utilisés et dotés de moins de fonctionnalités que les autres. En étudiant les différents logiciels disponibles, je me suis rendu compte que, par chance pour moi, beaucoup étaient codés en Python (3 sur 11 au total, mais surtout 3 sur les 5 vraiment intéressants). Ce n’est d’ailleurs pas la première fois que je constate, en cherchant à sélectionner des logiciels libres, que ceux codés en python sont à la fois les plus nombreux et les meilleurs.

Les cinq logiciels restants sont vraiment excellents, et constituent tous un bon choix. Trois d’entre eux, Docutils, Deplate et Pandoc, ont un design évolué, avec une machine à états finis pour laquelle on peut écrire de nouveaux readers et writers de manière parfaitement propre. Cependant, malgré leurs grandes qualités, Deplate est un projet trop confidentiel (ainsi il n’est incompréhensiblement pas présent parmi les pourtant si nombreux paquets Debian), et je ne me sentais pas à la hauteur pour m’investir dans un projet comme Pandoc, totalement écrit en Haskell, qui est un langage de programmation complexe que j’aimerais beaucoup utiliser, mais où ma compétence est encore trop limitée.

Il fallait donc que j’approfondisse ma réflexion sur les logiciels en Python :

Choix en Python

NomCibles principalesCible texte brut
Txt2tagsHTML, Latex et syntaxes WikiOui
DocutilsHTML et LatexNon
AsciiDocHTML et DocBookDump
MarkdownHTMLNon
TextileHTMLNon

J’ai rajouté dans ce comparatif Markdown et Textile, puisqu’ils ont chacun une implémentation en Python, mais ne générant que du HTML, ils ne m’intéressaient pas vraiment. AsciiDoc et Txt2tags ont un peu la même architecture, avec un gros fichier principal faisant tout le travail, que l’on peut configurer, respectivement avec un fichier .conf et deux dictionnaires Python (un pour les Tags et l’autre pour les Rules), pour créer de nouvelles cibles. AsciiDoc et Txt2tags sont donc plus aisés à prendre en main et à modifier rapidement que Docutils, qui est une très belle et très bien architecturée machine à états objet, mais aussi plus difficile à appréhender.

De plus, comme je désapprouvais totalement la politique de licence domaine publique de Docutils, il ne me restait plus qu’à faire mon choix entre Txt2tags et AsciiDoc. C’est principalement l’orientation très DocBook (un format ne m’intéressant personnellement pas du tout) d’AsciiDoc, et d’autres détails, comme la localisation en de nombreuses langues de Txt2tags et sa plus grande simplicité, qui m’ont finalement fait choisir Txt2tags.

Ce choix est confirmé par une étude plus avancée des différentes syntaxes. Ainsi alors que la syntaxe reST de Docutils ne dispose que de :

*italique* et **gras**

Txt2tags est beaucoup plus riche :

//italique// **gras** __souligné__ et --barré--

Le codage visuel est bien meilleur, et le compréhension instantanée avec la syntaxe de Txt2tags, puisque les slashs donnent l’impression penchée de l’italique, les étoiles imitent la surcharge du gras, les underscores donnent l’impression de soulignement, et les moins apparaissent comme une barre. De plus, l’utilisation généralisée des caractères de balisage en doubles, permet de lever à peu de frais un maximum d’ambiguïtés syntaxiques.

Par exemple une phrase aussi simple que celle contenue dans le fichier d’exemple de Txt2tags :

We use double *, /, - and _ to represent **bold**, //italic//, --strike-- and __underline__.

et qui ne pose aucun problème :

est en fait déjà trop ambigüe en reST, puisque :

We use double *, /, - and _ to represent **bold**, *italic*, strike and underline.

donnera :

De manière générale, la syntaxe reST est souvent trop lourde. Par exemple dans le cas de l’insertion d’une image servant de lien :

.. image:: picture.png
:target: http://fgallaire.flext.net

que l’on peut comparer avec le beaucoup plus simple Txt2tags :

[[picture.png] http://fgallaire.flext.net]

On remarque bien sûr ici que la syntaxe reST offre sûrement plein d’autres options que la simple :target:, et qu’elle est donc plus puissante que celle de Txt2tags. Cependant, mon avis est que la pénalité de lourdeur est toujours présente, alors qu’elle n’est utile que dans peut-être 1% des cas.

Voici maintenant un comparatif des logiciels disponibles par syntaxe :

Classement par syntaxe

UsageTxt2tagsAsciiDocreStructuredTextMarkdown
BureautiqueTxt2tagsAsciiDocDocutils
Pandoc
Pandoc
Web serveurTxt2tags (Python)
PHP
AsciiDoc (Python)Docutils (Python)Perl
Python
Ruby
PHP
Erlang
Java
Web clientmarked
Showdown
markdown-js

Leur implémentation en Python permet à Txt2tags, reST (par Docutils) et AsciiDoc d’être utilisables à la fois comme logiciels de bureautique multiplateforme (Linux, Mac OS X, Windows et *BSD) et pour le web côté serveur. Depuis 2012, une implémentation de txt2tags en PHP est disponible, développée par Petko Yotov (le mainteneur et principal développeur de PmWiki) et sponsorisée par Eric Forgeot. En face, Markdown est représenté par une armada d’implémentations dans tous les langages utilisés sur le web côté serveur, et aussi en JavaScript côté client pour des prévisualisation efficace sans Ajax, mais seul Pandoc, qui n’est pas si facile à compiler sur toutes les plateformes, propose autre chose qu’un rendu en HTML.

Je vais bien sûr continuer à travailler sur le logiciel Txt2tags, mais une implémentation de la syntaxe Txt2tags en JavaScript pour un rendu live sur le net, ainsi que des readers Pandoc, car j’ai vraiment envie de programmer en Haskell, et Docutils, pour pouvoir bénéficier ensuite du sublime Sphinx, sont des projets qui me motivent de plus en plus.

Enfin, je suis toujours un peu nostalgique devant ce screenshot, parce que c’est en le voyant, avec en haut à gauche le fichier avec les balises, et en bas à droite celui avec le résultat texte brut, que j’ai pris conscience que Txt2tags faisait bien ce que j’espérais, et que comme en plus il était en Python, ce serait probablement le logiciel auquel j’allais contribuer !

Mise à jour du 27 mai 2013 : Ajout dans le tableau comparatif des logiciels de Lunamark en Lua et de Jerome en Erlang. Ajout dans le tableau de classement par syntaxe de txt2tags-php.

Mise à jour du 26 février 2014 : Ajout dans le tableau comparatif des logiciels de Doxia et XWiki Rendering en Java. Ajout dans le tableau de classement par syntaxe de marked, markdown-js, erlmarkdown et XWiki Rendering.


Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

16 Responses to “Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile”

  1. Hello Florent,
    merci pour ce billet intéressant mais je suis géné sur un point : tu sembles confondre langage de balisage et implémentation. rst par exemple existe en dehors de docutils.

    Je suis dans la même reflexion pour remplacer dans mon entreprise LibreOffice pour la création de nos documents. Et même si je trouve un outil plus sympa que Sphinx, la popularité et la perinnité de ce dernier fait fortement balancer le choix en sa faveur.

    • fgallaire says:

      Oui, c’est pour bien séparer les deux que j’ai fait le dernier tableau, on peut y voir que Pandoc a un reader reST (même si il est moins complet que celui de Docutils).

  2. rst2pdf est un outil intéressant pour faire de la doc : http://code.google.com/p/rst2pdf/

    • fgallaire says:

      rst2pdf est basé sur docutils dont il utilise le ‘reader’ rst et la machine à états, c’est un ‘writer’ pdf direct (sans passer par LaTeX), grâce à l’utilisation de la bibliothèque ReportLab.

  3. PetitPierre94400 says:

    Comparaison intéressante mais pour la rédaction de documents techniques avancés (qui doivent répondre à certains standards industriels par exemple), ces solutions n’offrent pas assez de possibilités.

    @Sébastien: Pour le remplacement de notre “bureautique”, nous utilisons les produits de chez Altova. Je suis parfaitement conscient qu’il ne s’agit pas de logiciels libres mais ce sont les seuls à répondre entièrement à notre cahier des charges et surtout à nos besoins et attentes. Les possibilités sont telles que cela nous évite de nous lancer dans un bricolage couteux en temps et argent.

  4. Elessar says:

    J’ai envie de dire qu’il t’en manque, mais vu la profusion d’alternatives, ce serait difficile de tous les lister. Je tiens tout de même à mentionner Creole, qui est une syntaxe wiki commune. Rien à voir avec l’horrible syntaxe MediaWiki bien sûr.

    • fgallaire says:

      Coucou,

      Creole est une démarche intéressante de tentative d’unification des syntaxes wiki, j’ai mis dans l’article un lien vers la réflexion qu’ils ont menée qui est très bien documentée et argumentée.
      D’ailleurs ils sont arrivés aux même conclusion que Txt2tags sur pas mal de points. Pour reprendre mon exemple sur le gras et l’italique :
      http://www.wikicreole.org/wiki/BoldAndItalicsReasoning
      “A star (*) is the most used symbol to bold text online. A slash (/) looks like slanted italics, so it is intuitive and thus easier to remember. Double symbols are generally used in Creole to avoid accidentally parsing text not meant to be parsed.”
      Par contre il n’y a pas d’implémentation de Creole qui produise autre chose que du HTML…Donc je ne crois pas avoir oublié de logiciel qui corresponde à ma comparaison.

  5. eric says:

    Salut Florent,

    Avec la rude concurrence qu’il y a dans ce créneau, c’est quand même une chance pour txt2tags de t’avoir récupéré comme développeur !

    Dommage qu’Aurélio n’ait pas répondu par rapport à ta demande de sortir une nouvelle version de txt2tags (2.7), car vu les nouveautés de la version de développement ça serait vraiment le bon moment. Sans doute qu’il est pris avec beaucoup d’autres projets, et que la charge de travail que ça implique (et que ça a fait pour la 2.6) lui fait peur. Je suis plutôt partisan du « Release early, release often », non seulement parce que ça permet de procurer aux utilisateurs une version à jour des dernières fonctionnalités, mais aussi parce que ça permet de donner un prétexte à « faire du buzz » autour, en impliquant une dynamique, un événement autour de la sortie.

    Le mode de distribution de txt2tags, un seul fichier python + la doc, fait qu’il n’est pas bien compliqué de revenir à la version précédente si l’utilisateur le souhaite (mais a priori il n’y a jamais vraiment eu de problème compatibilité avec les anciens fichiers écrit en txt2tags).

    Une implémentation javascript de txt2tags serait vraiment super, et également une version php, sur le modèle de http://michelf.com/projects/php-markdown/

    Bien entendu, pas (forcément) besoin de permettre tout ce que permet txt2tags (macro, export dans 30 formats), le support de la syntaxe serait grandement suffisant, et permettrait de faire entrer txt2tags là où est déjà markdown (plugins wordpress etc).

    Bref, comme tu l’indiques, la syntaxe particulièrement logique de txt2tags me semble un de ses points forts, et si Creole va dans le bon sens, ça ne semble pas beaucoup bouger de son côté, c’est pourquoi je trouve qu’il faut porter txt2tags le plus en avant possible, pour qu’il soit pris en compte par de plus en plus de projets, que cela soit coloration syntaxique dans les éditeurs de texte, ou « syntaxe wiki » par défaut sur des sites de discussion ou des wiki en ligne.

    À ce sujet, j’apprécie particulièrement l’interface de Rednotebook, qui sans être wysiwyg, affiche un aperçu du rendu (//ce texte// sera affiché en italique), tout en gardant la syntaxe wiki sous-jacente (j’ai essayé de faire pareil dans les colorations syntaxique des éditeurs geany et de kate). Ça serait super de pouvoir proposer cela dans une interface web, pour l’édition de texte.

    Sinon, toi qui t’intéresse à l’ASCII art, peut-être connais-tu Ditaa, si ce n’est pas le cas je te conseille d’aller voir ce qu’on peut faire avec :

    http://ditaa.org/ditaa/

    • fgallaire says:

      Coucou Eric,

      Merci de ton message, txt2tags a aussi beaucoup de chance de t’avoir toi !
      Aurelio est toujours débordé (un peu comme nous tous :-)), mais comme tu l’as précisé une release c’est BEAUCOUP de travail d’un coup, et même si je pense moi aussi que le plus souvent serait le mieux, je comprends qu’il ne se presse pas trop ^^.
      RedNotebook est effectivement très innovant, j’en parlerai dans un futur article, tout comme de ditaa d’ailleurs.

  6. Un tour d’horizon intéressant surtout quand le but est bien de se concentrer sur le fond d’abord et la forme ensuite (ce qu’on ne sait pas faire facilement avec les outils “à la” LibreOffice). Ça fait plaisir de ne pas être le seul à la recherche de ce graal.

    Ceci dit j’ai juste une petite remarque.

    Certes txt2tags est plus riche que rest et docutils pour la mise en forme (**gras**, //italique//, __souligné__ et –barré–) mais du coup on perd en sémantique et on remets de la forme là où il ne devrait pas y en avoir.

    De ce point de vue là, j’aime bien l’approche Markdown (juste pour cet aspect là au moins) : *emphase* et **emphase forte** (même si j’aurais préféré “emphase” et *emphase forte*).

  7. Eric says:

    Une réponse un peu tardive… mais pour l’utilisateur moyen (ce qui n’est pas forcément la cible de txt2tags, mais pourrait l’être d’un langage de balisage léger), la “sémantique” n’a pas beaucoup de sens : les gens veulent souligner ou mettre en gras ou mettre en italique parce que ça a du sens pour eux.

    Quoi qu’il en soit, la syntaxe de txt2tags n’est pas figée (contrairement celle de Markdown, qui en plus est lacunaire), si par exemple on préfère sortir du à la place de la balise et du à la place de , on peut utiliser les règles suivantes :

    %!postproc: ‘‘ ‘
    %!postproc: ‘
    ‘ ‘

    %!postproc: ‘‘ ‘
    %!postproc: ‘
    ‘ ‘‘

    D’autre part, pour en revenir sur l’intérêt des langages de balisage léger par rapport à du WYSIWYG, c’est que lorsqu’on marque un mot, il sera correctement délimité, juste le mot sera , par exemple :
    Je pense que **ceci** est important

    Dans beaucoup de documents html ou .doc que l’on trouve et qu’on veut retraiter, au contraire lorsqu’un mot est marqué, ça prend souvent l’espace avant ou après le mot (résultat de la sélection approximative de celui-ci), et c’est une horreur pour retravailler ensuite un tel document.

  8. [...] Dans Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, Asc…, ajout dans le tableau comparatif des logiciels de balisage léger de Lunamark en Lua et de Jerome en Erlang. [...]

  9. tetue says:

    Je suis en train d’étudier différentes syntaxes et mon attention s’est aussi portée sur Txt2tags pour sa lisibilité en texte brut. Merci pour cet article très intéressant :)

  10. […] J’ai donc ajouté XWiki Rendering et Doxia (oui j’avais précédemment un peu oublié le monde Java)  dans le tableau comparatif des logiciels de balisage léger de Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, Asc…. […]

  11. Merci Florent d’avoir ajouté XWiki Rendering :)

  12. c1coucou2piou says:

    De plus txt2tags possède un avantage sur nombre de ses //concurrents// : il est possible d’inclure des sous-fichiers txt2tags. Un plus indéniable quand le document édité commence à être consèquent => on peut le découper en plusieurs fichiers. Merci pour cet outil

Leave a Reply