Le moyen le plus simple de mettre en forme et de produire des documents XML DocBook est d'utiliser la chaîne logicielle xmlto. Elle est intégrée à la distribution Red Hat et les utilisateurs de Debian peuvent la récupérer via la commande apt-get install xmlto.

Pour produire du XHTML à partir de vos sources DocBook, il vous faudra normalement faire quelque-chose comme ceci :

bash$ xmlto xhtml foo.xml
bash$ ls *.html
ar01s02.html ar01s03.html ar01s04.html index.html

Dans cet exemple, vous avez converti un document XML Docbook nommé foo.xml composé de trois sections principales en une page d'index et trois parties. Produire une seule page est tout aussi simple :

bash$ xmlto xhtml-nochunks foo.xml
bash$ ls *.html
foo.html

Enfin, voici comment produire du PostScript pour l'impression :

bash$ xmlto ps foo.xml     # Production de PostScript
bash$ ls *.ps
foo.ps

Certaines versions plus anciennes de xmlto peuvent être plus bavardes en émettant de messages du type « Conversion en XHTML en cours » et ainsi de suite.

Pour convertir vos documents en HTML ou en PostScript, vous devez disposer d'un moteur capable d'appliquer à la fois la DTD DocBook et une feuille de style adéquate à votre document. Voici comment s'intègrent ensemble les outils libres utilisés à cette fin :

Chaîne logicielle XML DocBook actuelle

L'analyse du votre document et l'application de la feuille de style vont être réalisées par l'un des programmes suivants. Le plus courant est xsltproc, l'analyseur inclus dans la distribution Red Hat depuis la version 7.3. Les autres possibilités sont les programmes Java Saxon et Xalan.

XHTML étant simplement une autre DTD XML, il est relativement aisé de produire du XHTML de haute qualité à partir de DocBook. La conversion en HTML est réalisée en appliquant une feuille de style plutôt simple et c'est à peu près tout. De même RTF est simple à produire de cette manière et il est facile de produire un fichier de texte brut à partir d'XHTML ou de RTF.

Le cas de l'impression est moins évident. Il est difficile de produire des impressions de haute qualité (ce qui correspond en pratique au format PDF^[2] d'Adobe, une version prête à l'emploi de PostScript). Pour le faire correctement, il est nécessaire de reproduire de manière algorithmique la finesse du jugement humain utilisé par un typographe lorsqu'il passe du niveau du contenu à celui de la présentation.

Donc, premièrement, une feuille de style traduit le balisage structurel DocBook en un autre langage XML — FO (Formatting Objects). Le balisage FO est un vrai balisage de présentation. Vous pouvez le considérer comme un équivalent fonctionnel de troff dans le monde XML. Il doit être traduit en Postscript pour pouvoir être intégré à un PDF.

Dans la chaîne logicielle intégrée à Red Hat, ce travail est pris en charge par un paquet de macros TeX appelé PassiveTeX. Il traduit dans le langage TeX de Donald Knuth les objets de mise en formes produits par xsltproc. TeX a été un des tous premiers projets libres, un langage de mise en forme (au niveau de la présentation) ancien mais puissant, apprécié des mathématiciens (à qui il fournit des fonctionnalités particulièrement évoluées de description des notations mathématiques). TeX est également connu pour son efficacité dans les tâches typographiques de base comme le crénage, le remplissage de lignes ou la césure. Le résultat de l'exécution de TeX, récupéré dans un format appelé DVI (DeVice Independent), est ensuite transformé en PDF.

Si vous trouvez que cet enchaînement de XML vers des macros TeX vers DVI vers PDF ressemble à une usine à gaz, vous n'avez pas tort. Ça grince, ça siffle et ça comporte d'horribles verrues. Les fontes constituent un problème important du fait qu'XML, TeX et PDF possèdent des modèles très différents d'utilisation des fontes. En outre, la gestion de l'internationalisation et des paramètres régionaux est un vrai cauchemar. La seule chose qui justifie cet enchaînement est que cela fonctionne.

La solution élégante sera FOP, un traducteur FO vers PostScript développé par le projet Apache. Avec FOP, le problème de l'internationalisation est, s'il n'est pas résolu, bien circonscrit : les outils XML manient l'Unicode de bout en bout. La correspondance entre glyphes et fonte est également un problème relevant strictement de FOP. Le seul problème de cette approche est que cela ne fonctionne pas — du moins pour le moment. En date d'août 2002, FOP est en version alpha non finalisée — utilisable mais brut de décoffrage et fonctionnellement incomplet.

Voici à quoi ressemble la chaîne logicielle FOP :

Future chaîne logicielle XML DocBook intégrant FOP

FOP a des concurrents. Il existe un autre projet appelé xsl-fo-proc qui vise le même objectif que FOP, mais en C++ (et donc plus rapide et ne reposant pas sur l'environnement Java). En date d'août 2002, xsl-fo-proc est aussi en version alpha non finalisée, dans un état assez proche de celui de FOP.