<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
<!ENTITY howto "http://www.traduc.org/docs/howto/lecture/">
<!ENTITY guide "http://www.traduc.org/docs/guides/lecture/">
<!ENTITY home "http://www.catb.org/~esr/">
<!ENTITY images "">
]>
<article lang="fr">
<articleinfo>
<title>Comprendre DocBook (Guide pratique)</title>
<subtitle>
Version française du guide pratique <foreignphrase
lang="en">DocBook Demystification HOWTO</foreignphrase>
</subtitle>
<releaseinfo>Version : 1.3.fr.1.2</releaseinfo>
<pubdate>11 juin 2008</pubdate>
<author>
<firstname>Eric</firstname>
<surname>Raymond</surname>
<email>esr CHEZ thyrsus POINT com</email>
</author>
<othercredit role="traduction" class="translator">
<firstname>Raphaël</firstname>
<surname>Semeteys</surname>
<contrib>Adaptation française</contrib>
<email>raphael POINT semeteys CHEZ wanadoo POINT fr</email>
</othercredit>
<othercredit role="relecture" class="translator">
<firstname>Jean-Philippe</firstname>
<surname>Guérard</surname>
<contrib>Relecture de la version française</contrib>
<email>fevrier CHEZ tigreraye POINT org</email>
</othercredit>
<othercredit role="publication" class="copyeditor">
<firstname>Jean-Philippe</firstname>
<surname>Guérard</surname>
<contrib>Préparation de la publication de la v.f.</contrib>
<email>fevrier CHEZ tigreraye POINT org</email>
</othercredit>
<revhistory>
<revision>
<revnumber>1.3.fr.1.2</revnumber>
<date>2008-06-11</date>
<authorinitials>JPG</authorinitials>
<revremark>
Correction d'une petite coquille. Merci Joris Rehm de nous
l'avoir signalé. Remplacement d'un lien obsolète vers le livre
« XML en concentré » (qui n'est plus édité) par un
lien vers sa version originale.
</revremark>
</revision>
<revision>
<revnumber>1.3.fr.1.1</revnumber>
<date>2007-04-26</date>
<authorinitials>JPG</authorinitials>
<revremark>
Modification du titre français.
</revremark>
</revision>
<revision>
<revnumber>1.3.fr.1.0</revnumber>
<date>2006-01-07</date>
<authorinitials>RSS, JPG</authorinitials>
<revremark>
Adaptation française initiale.
</revremark>
</revision>
<revision>
<revnumber>1.3</revnumber>
<date>2004-02-27</date>
<authorinitials>ESR</authorinitials>
<revremark>
Ajout de pointeurs vers deux éditeurs. <emphasis
lang="en">Add pointers to two editors.</emphasis>
</revremark>
</revision>
<revision>
<revnumber>1.2</revnumber>
<date>2003-02-17</date>
<authorinitials>ESR</authorinitials>
<revremark>
Déplacement des références à SGML après que celui-ci ait été
présenté. <emphasis lang="en">Reorder to defer references to
SGML until after it has been introduced.</emphasis>
</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>2002-10-01</date>
<authorinitials>ESR</authorinitials>
<revremark>
Correction d'une erreur faite par inadvertance sur la
position de la FSF. Ajout d'un pointeur vers la FAQ DocBook.
<emphasis lang="en">Correct inadvertent misrepresentation of
FSF's position. Added pointer to the DocBook FAQ.</emphasis>
</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>2002-09-20</date>
<authorinitials>ESR</authorinitials>
<revremark>
Version initiale. <emphasis lang="en">Initial
version.</emphasis>
</revremark>
</revision>
</revhistory>
<abstract><para>
Ce guide pratique tente de dissiper le brouillard et le mystère
entourant le système de balisage DocBook et les outils associés. Il
est destiné aux auteurs de documentations techniques pour les projets
libres sous Linux, mais devrait également être utile à la rédaction
d'autres types de documents sur d'autres systèmes Unix.
</para></abstract>
</articleinfo>
<sect1 id="intro">
<title>Introduction</title>
<para>
Bon nombre de grands projets libres sont en train de converger vers
l'utilisation du format DocBook comme format standard de documentation
— des projets comme le noyau Linux, GNOME, KDE, Samba et le Projet
de documentation Linux (LDP). Les défenseurs du balisage structurel basé
sur XML (par opposition au style plus ancien de balisage de présentation
illustré par troff, Tex et Texinfo) semblent avoir gagné la bataille
théorique. Il est possible de produire un balisage de présentation à
partir d'un balisage structurel, mais l'inverse est très difficile.
</para>
<para>
Néanmoins, une grande confusion entoure DocBook et les programmes qui
l'accompagnent. Ses adeptes parlent un argot dense et intimidant, même
selon les canons de l'informatique, utilisant à tout va des sigles sans
rapport évident avec ce qui doit être fait pour écrire du texte balisé
et produire du HTML ou du Postscript. Les standards et les documents
techniques sur XML sont notoirement obscurs.
</para>
<para>
Ce guide va tenter de clarifier les principaux mystères existants autour
de DocBook et de son utilisation pour les documents relatifs aux
logiciels libres — qu'il s'agisse de documentations techniques ou
politiques. Notre objectif est de vous permettre de comprendre non
seulement ce que vous devez faire pour fabriquer des documents, mais
aussi pourquoi le processus est si complexe — et comment on peut
s'attendre à voir cela changer au fur et mesure de la disponibilité de
nouveaux outils DocBook.
</para>
</sect1>
<sect1>
<title>Pourquoi s'intéresser à DocBook ?</title>
<para>
DocBook offre deux possibilités qui le rendent vraiment intéressant. La
première est la <emphasis>production multi-formats</emphasis> et la
seconde la réalisation de <emphasis>bases de documents
interrogeables</emphasis>.
</para>
<para>
La <emphasis>production multi-formats</emphasis> est la possibilité la
plus simple et la plus proche de la réalisation ; il s'agit de la
capacité à écrire un document dans un format maître unique, qui puisse
être utilisé pour produire différents formats d'affichage (en
particulier du HTML pour la visualisation en ligne et du Postscript pour
des impressions de haute qualité). Cette capacité est désormais assez
bien mise en œuvre.
</para>
<para>
Le terme <emphasis>base de documents interrogeable</emphasis> est une
manière condensée d'expliquer que DocBook puisse nous aider à aller vers
un monde où l'ensemble de la documentation présente sur votre système
d'exploitation libre constituera une base de données hypertexte, indexée
et interrogeable de textes enrichis (plutôt que d'être éparpillée dans
des formats variés en de multiples endroits comme c'est le cas
aujourd'hui).
</para>
<para>
Idéalement, lorsque vous installerez un logiciel sur votre machine, il
enregistrera sa documentation DocBook dans le catalogue de votre
système. Celui-ci produira automatiquement du HTML correctement indexé
et interconnecté au HTML contenu dans le reste de votre catalogue. La
documentation du nouveau paquet sera alors disponible via un navigateur.
Des recherches pourront être réalisés sur l'ensemble de la documentation
via une interface ressemblant à un bon moteur de recherche.
</para>
<para>
Le HTML en tant que tel n'est pas un format suffisamment riche pour nous
rapprocher de ce monde. Pour ne citer qu'une seule de ses lacunes, le
HTML ne permet pas de déclarer explicitement des entrées d'index.
DocBook <emphasis>possède</emphasis> la richesse sémantique permettant
la réalisation de bases de documents structurées. C'est la raison
fondamentale de son adoption par de si nombreux projets.
</para>
<para>
DocBook a les inconvénients de ses avantages. Certains le trouvent trop
lourd et verbeux pour pouvoir réellement constituer un format de
composition confortable. Ce qui ne posera pas de problème, tant que les
formats qu'ils affectionnent (comme le format POD de Perl ou le Texinfo
GNU) disposent de moteurs permettant de produire du DocBook, tout le
monde sera satisfait. Peu importe que tout le monde écrive au format
DocBook ou pas. Du moment que DocBook devient le format commun d'échange
de documents, nous resterons capables de réaliser des bases de documents
interrogeables unifiées.
</para>
</sect1>
<sect1>
<title>Balisage structurel : préambule</title>
<para>
Les anciens langages de mise en forme tels que Tex, Texinfo ou Troff
permettaient de réaliser un <firstterm>balisage de
présentation</firstterm><indexterm>
<primary>balisage de présentation</primary>
</indexterm>. Les instructions que vous donniez à ces systèmes
concernaient l'apparence et la disposition physique du texte (par
exemple, des modifications de la fonte ou de l'indentation).
</para>
<para>
Tant que votre objectif restait d'imprimer sur un seul support ou un
seul type de périphérique d'affichage, le balisage de présentation
restait une bonne solution. Vous en atteignez les limites lorsque vous
commencez à baliser un document en voulant (a) qu'il puisse être mis en
forme pour des dispositifs d'affichages très différents (comme des
imprimantes et le web) ou (b) réaliser des recherches sur le document et
l'indexer via sa structure logique (par exemple pour l'incorporer dans
un système hypertexte).
</para>
<para>
Pour disposer de ces capacités, vous aurez besoin d'un système de
<firstterm>balisage structurel</firstterm><indexterm>
<primary>balisage structurel</primary>
</indexterm>. Avec le balisage structurel, vous ne décrirez pas
l'apparence physique du document mais plutôt les propriétés logiques de
ses différentes parties.
</para>
<para>
Par exemple : dans un langage de balisage de présentation, si vous
désirez accentuer un mot, vous indiquerez à l'outil de mise en forme de
le mettre en caractères gras. Dans
<citerefentry>
<refentrytitle>troff</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>
cela ressemblera à ceci<footnote><para>
N.D.T. : les fautes sont volontaires. Pour comprendre cette
référence, jetez un œil à l'article Wikipédia <ulink
url="http://fr.wikipedia.org/wiki/All_your_base_are_belong_to_us">correspondant</ulink>.
</para></footnote> :
</para>
<programlisting>
Toutes vos base
.B sont
appartiennent à nous !
</programlisting>
<para>
Dans un langage de balisage structurel, vous indiquerez à l'outil de
mise en forme de mettre le en relief :
</para>
<programlisting>
Toutes vos base <emphasis>sont</emphasis>
appartiennent à nous !
</programlisting>
<para>
Le <quote><sgmltag class="starttag">emphasis</sgmltag></quote> et le
<quote><sgmltag class="endtag">emphasis</sgmltag></quote> de la ligne
précédente sont appelés des <firstterm>balises de
marquage</firstterm><indexterm>
<primary>balise de marquage</primary>
</indexterm> ou tout simplement des <firstterm>balises</firstterm>.
Elles constituent les instructions de votre outil de mise en forme.
</para>
<para>
Dans un langage de balisage structurel, l'apparence physique du document
final sera contrôlée par l'application d'une <firstterm>feuille de
style</firstterm><indexterm>
<primary>feuille de style</primary>
</indexterm>. C'est la feuille de style qui indiquera à l'outil de mise
en forme de <quote>représenter la mise en relief sous forme de
caractères gras</quote>. Un des avantages des langages de balisage
structurel est qu'en modifiant une feuille de style vous pourrez
modifier de manière globale la présentation du document (pour utiliser
des polices de caractères différentes par exemple) sans avoir à modifier
chaque occurrence, par exemple, de <markup>.B</markup> dans le document
lui-même.
</para>
</sect1>
<sect1>
<title>Définitions de types de documents (DTD)</title>
<note><para>
Pour rester simple dans notre explication, cette section comporte
certains raccourcis historiques qui seront corrigés dans une <link
linkend="sgml">section ultérieure</link>.
</para></note>
<para>
DocBook est un langage de balisage structurel. Plus spécifiquement c'est
un dialecte XML. Un document DocBook est un fichier XML qui utilise des
balises XML pour définir sa structure.
</para>
<para>
Afin d'appliquer une feuille de style à votre document et de lui donner
une belle apparence, un outil de mise en forme aura besoin de savoir
certaines choses sur la structure complète du document. Par exemple, il
aura besoin de savoir qu'un livre est normalement constitué de parties
liminaires, d'une suite de chapitres, puis de parties annexes afin de
pouvoir mettre en forme correctement les en-têtes de chapitres. Afin
qu'il puisse le savoir, vous devrez lui fournir une
<firstterm>définition de type de document</firstterm><indexterm>
<primary>définition de type de document</primary>
<secondary>DTD</secondary>
</indexterm> ou DTD. La DTD
indique à l'outil de mise en forme les éléments qui peuvent se trouver
dans la structure du document ainsi que l'ordre dans lequel ils peuvent
apparaître.
</para>
<para>
Lorsqu'on décrit DocBook comme une application de XML, on veut dire
par là qu'il s'agit d'une DTD — une DTD plutôt conséquente avec
près de 400 balises.
</para>
<para>
Derrière DocBook se cache un type de programme appelé un
<firstterm>analyseur de validation</firstterm><indexterm>
<primary>analyseur de validation</primary>
</indexterm>. Lorsque vous mettez en forme un document DocBook, la
première étape à franchir est de le passer au crible d'un analyseur de
validation (qui est le premier composant de l'outil de mise en forme
DocBook). Ce programme vérifie la validité de votre document par rapport
à la DTD DocBook. Cela permet de s'assurer que vous n'êtes en conflit
avec aucune des règles structurelles de la DTD (sinon le composant de
l'outil de mise en forme en charge de l'application de la feuille de
style pourrait s'y perdre).
</para>
<para>
L'analyseur de validation va soit vous afficher des messages d'erreurs
relatifs aux endroits où la structure du document est incorrecte, soit
traduire le document en un flux d'<firstterm>évènements de mise en
forme</firstterm> qui sera finalement combiné avec votre feuille de
style pour produire le résultat mis en forme.
</para>
<para>Voici un schéma du processus complet :</para>
<mediaobject>
<imageobject>
<imagedata fileref="&images;schema-01.png" role="html" format="PNG"/>
</imageobject>
<imageobject>
<imagedata fileref="&images;schema-01.svg" role="fo" format="SVG"/>
</imageobject>
</mediaobject>
<para>
La partie du schéma comprise dans la zone en pointillés est votre outil
de mise en forme, autrement appelée votre <firstterm>chaîne
logicielle</firstterm> de mise en forme. Pour comprendre ce qui suit, en
plus de l'entrée évidente et visible de l'outil de mise en forme (le
document source) vous devrez garder en tête les deux autres entrées
<quote>cachées</quote> (DTD et feuille de style) de l'outil de mise en
forme.
</para>
</sect1>
<sect1><title>Autres DTD</title>
<para>
Un court détour par les autres DTD vous aidera à distinguer les parties
de la section précédente qui sont spécifiques à DocBook de celles
concernant tous les langages de balisage structurel.
</para>
<para>
<ulink url="http://www.tei-c.org/">TEI</ulink> (Text Encoding
Initiative) est une DTD conséquente et élaborée, principalement utilisée
dans les milieux académiques pour la transcription informatique de
textes littéraires. La chaîne logicielle de TEI, fonctionnant sous Unix,
utilise nombre d'outils utilisés par DocBook, mais avec des feuilles de
style et (évidemment) une DTD différentes.
</para>
<para>
XHTML, la dernière version de HTML, est également une utilisation d'XML
décrite par une DTD, ce qui explique l'air de famille existant entre les
balises XHTML et DocBook. La chaîne logicielle XHTML est constituée de
navigateurs web et d'un certain nombre d'utilitaires spécifiques
d'impression.
</para>
<para>
De nombreuses autres DTD XML sont maintenues afin de faciliter les
échanges d'informations structurées dans des domaines aussi divers que
l'informatique biologique ou la banque. Vous pouvez consulter la <ulink
url="http://www.xml.com/pub/rg/DTD_Repositories">liste des
référentiels</ulink> pour vous faire une idée de la variété des DTD
existantes.
</para>
</sect1>
<sect1><title>La chaîne logicielle DocBook</title>
<para>
Le moyen le plus simple de mettre en forme et de produire des documents
XML DocBook est d'utiliser la chaîne logicielle
<application>xmlto</application>. Elle est intégrée à la distribution
Red Hat et les utilisateurs de Debian peuvent la récupérer via la
commande <userinput>apt-get install xmlto</userinput>.
</para>
<para>
Pour produire du XHTML à partir de vos sources DocBook, il vous faudra
normalement faire quelque-chose comme ceci :
</para>
<screen>
bash$ xmlto xhtml foo.xml
bash$ ls *.html
ar01s02.html ar01s03.html ar01s04.html index.html
</screen>
<para>
Dans cet exemple, vous avez converti un document XML Docbook nommé
<filename>foo.xml</filename> composé de trois sections principales en
une page d'index et trois parties. Produire une seule page est tout
aussi simple :
</para>
<screen>
bash$ xmlto xhtml-nochunks foo.xml
bash$ ls *.html
foo.html
</screen>
<para>
Enfin, voici comment produire du PostScript pour l'impression :
</para>
<screen>
bash$ xmlto ps foo.xml # Production de PostScript
bash$ ls *.ps
foo.ps
</screen>
<para>
Certaines versions plus anciennes de <command>xmlto</command> peuvent
être plus bavardes en émettant de messages du type <quote>Conversion en
XHTML en cours</quote> et ainsi de suite.
</para>
<para>
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 :
</para>
<mediaobject>
<imageobject>
<imagedata fileref="&images;schema-02.png" role="html" format="PNG"/>
</imageobject>
<imageobject>
<imagedata fileref="&images;schema-02.svg" role="fo" format="SVG"/>
</imageobject>
<caption>
<para>Chaîne logicielle XML DocBook actuelle</para>
</caption>
</mediaobject>
<para>
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
<application>xsltproc</application><indexterm>
<primary>xsltproc</primary>
</indexterm>,
l'analyseur inclus dans la distribution Red Hat depuis la version 7.3.
Les autres possibilités sont les programmes Java
<application>Saxon</application><indexterm>
<primary>Saxon</primary>
</indexterm>
et
<application>Xalan</application><indexterm>
<primary>Xalan</primary>
</indexterm>.
</para>
<para>
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.
</para>
<para>
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<indexterm>
<primary>PDF</primary>
</indexterm><footnote><para>
PDF signifie Format Portable de Document — <foreignphrase
lang="en">Portable Document Format</foreignphrase> dans la langue de
Shakespeare.
</para></footnote> 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.
</para>
<para>
Donc, premièrement, une feuille de style traduit le balisage structurel
DocBook en un autre langage XML —
FO<indexterm>
<primary>FO</primary>
</indexterm>
(<foreignphrase lang="en">Formatting Objects</foreignphrase>). 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.
</para>
<para>
Dans la chaîne logicielle intégrée à Red Hat, ce travail est pris en
charge par un paquet de macros TeX appelé
<application>PassiveTeX</application><indexterm>
<primary>PassiveTeX</primary>
</indexterm>.
Il traduit dans le langage TeX de Donald Knuth les objets de mise en
formes produits par <command>xsltproc</command>. 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 (<foreignphrase lang="en">DeVice Independent</foreignphrase>)<indexterm>
<primary>DVI</primary>
</indexterm>,
est ensuite transformé en PDF.
</para>
<para>
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.
</para>
<para>
La solution élégante sera
FOP<indexterm>
<primary>FOP</primary>
</indexterm>,
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.
</para>
<para>Voici à quoi ressemble la chaîne logicielle FOP :</para>
<mediaobject>
<imageobject>
<imagedata fileref="&images;schema-03.png" role="html" format="PNG"/>
</imageobject>
<imageobject>
<imagedata fileref="&images;schema-03.svg" role="fo" format="SVG"/>
</imageobject>
<caption>
<para>Future chaîne logicielle XML DocBook intégrant FOP</para>
</caption>
</mediaobject>
<para>
FOP a des concurrents. Il existe un autre projet appelé
<application>xsl-fo-proc</application><indexterm>
<primary>xsl-fo-proc</primary>
</indexterm>
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,
<application>xsl-fo-proc</application> est aussi en version alpha non
finalisée, dans un état assez proche de celui de FOP.
</para>
</sect1>
<sect1><title>Quels sont les projets et les acteurs ?</title>
<para>
La DTD DocBook elle-même est maintenue par le Comité technique DocBook
(<foreignphrase lang="en">DocBook Technical Committee</foreignphrase>),
dirigé par Norman Walsh. Norm est le principal auteur des feuilles de
style DocBook. Il a consacré depuis de nombreuses années une grande
quantité d'énergie et de talent aux problèmes extrêmement complexes
qu'aborde DocBook. Il est autant respecté dans la communauté DocBook que
l'est Linus Torvalds dans le monde Linux.
</para>
<para>
<ulink url="http://xmlsoft.org/XSLT/">libxslt</ulink> est une
bibliothèque C qui interprète XSLT et applique les feuilles de style aux
documents XML. Elle comprend un utilitaire, <command>xsltproc</command>,
qui peut être utilisé comme outil de mise en forme XML. Son code a été
écrit par Daniel Veillard sous les auspices du projet GNOME, mais ne
requiert aucun code GNOME pour fonctionner. J'ai entendu dire qu'elle
était extraordinairement plus rapide que ses alternatives Java, ce qui
n'est pas une affirmation très surprenante.
</para>
<para>
<command><ulink
url="http://cyberelk.net/tim/xmlto/">xmlto</ulink></command> est
l'interface utilisateur de la chaîne logicielle intégrée à Red Hat. Elle
est écrite et maintenue par Tim Waugh.
</para>
<para>
<ulink url="http://saxon.sourceforge.net/">Saxon</ulink> et <ulink
url="http://xml.apache.org/xalan-j/">Xalan</ulink> sont des programmes
Java qui interprètent XSLT. Saxon semble être conçu pour fonctionner
sous Windows. Xalan fait partie du projet XML Apache et fonctionne
directement sous Linux et BSD. Il est conçu pour fonctionner avec FOP.
</para>
<para>
<ulink url="http://xml.apache.org/fop/">FOP</ulink> traduit des objets
de mise en forme XML (FO) en PDF. Il fait partie du projet XML Apache et
est conçu pour fonctionner avec Xalan.
</para>
</sect1>
<sect1><title>Outils de migration</title>
<para>
Le deuxième plus gros problème de DocBook est l'effort nécessaire pour
convertir les anciens balisages de présentation en balisage DocBook. Les
êtres humains sont généralement capables de convertir automatiquement la
présentation d'un document en une structure logique, parce qu'ils sont,
par exemple, capables de distinguer selon le contexte les cas où
l'italique est utilisé comme moyen d'accentuation de ceux où il signifie
autre chose, comme le fait que la phrase soit en langue étrangère.
</para>
<para>
D'une façon ou d'une autre, il est nécessaire rendre explicite ce type
de distinctions lors de la conversion de documents vers le format
DocBook. Parfois elles sont présentes dans l'ancien balisage mais ce
n'est en général pas le cas et l'information de structure manquante
doit, soit être déduite par une heuristique intelligente, soit être
ajoutée par un être humain.
</para>
<para>
Voici un résumé de l'état des outils de conversion à partir de divers
autres formats :
</para>
<variablelist>
<varlistentry>
<term>GNU Texinfo</term>
<listitem>
<para>
La <emphasis lang="en">Free Software Foundation</emphasis> s'est fixé
comme politique de permettre d'utiliser DocBook comme format d'échange.
Texinfo est suffisamment structuré pour permettre une conversion
automatique satisfaisante, et les versions 4.x de
<command>makeinfo</command> proposent une option
<option>--docbook</option> qui produit directement du format DocBook.
Vous trouverez plus d'information sur la <ulink
url="http://www.gnu.org/directory/texinfo.html">page du projet
makeinfo</ulink>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>POD</term>
<listitem>
<para>
Il existe un module <ulink
url="http://www.cpan.org/modules/by-module/Pod/">POD::DocBook</ulink>
qui traduit le balisage POD (<foreignphrase lang="en">Plain Old
Documentation</foreignphrase>) en DocBook. Il prétend traduire
l'intégralité des balises POD sauf la balise italique L<>. La page
de manuel précise également <quote>Il n'est pas possible d'utiliser de
listes imbriquées pour une sortie en DocBook</quote> et fait remarquer
que le module a été intensivement testé.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LaTeX</term>
<listitem>
<para>
LaTeX est (essentiellement) un langage de macros de balisage structurel
construit au-dessus de l'outil de mise en forme TeX. Il existe un projet
appelé <ulink
url="http://www.lrz-muenchen.de/services/software/sonstiges/tex4ht/mn.html">TeX4ht</ulink>
qui (selon l'auteur de PassiveTeX) est capable de produire du code
DocBook à partir de LaTeX.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Pages de manuels et balisages basées sur troff</term>
<listitem>
<para>
On considère généralement qu'il s'agit du problème de conversion le plus
important et le plus désagréable. Et en effet le balisage de base de
<citerefentry>
<refentrytitle>troff</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>
possède un niveau de présentation trop bas pour que des outils de
conversions puissent apporter quelque aide que ce soit. Cependant la
situation s'éclaircit significativement si l'on considère les
traductions de documents écrits avec des paquets de macros comme
<citerefentry>
<refentrytitle>man</refentrytitle>
<manvolnum>7</manvolnum>
</citerefentry>.
Ceux-ci sont suffisamment structurés pour permettre une traduction
automatique.
</para>
<para>
J'ai moi-même écrit un outil pour ce faire car je n'en trouvé aucun
capable de faire proprement le travail (et également parce que le
problème est intéressant). Il s'appelle <ulink
url="&home;/doclifter/">doclifter</ulink>. Il convertit au format SGML
ou XML DocBook les macros
<citerefentry>
<refentrytitle>man</refentrytitle>
<manvolnum>7</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>mdoc</refentrytitle>
<manvolnum>7</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>ms</refentrytitle>
<manvolnum>7</manvolnum>
</citerefentry>
ou
<citerefentry>
<refentrytitle>me</refentrytitle>
<manvolnum>7</manvolnum>
</citerefentry>.
Consultez la documentation pour plus d'informations.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1><title>Outils d'édition</title>
<para>
Il nous manque actuellement est un bon éditeur structurel libre pour les
documents SGML et XML.
</para>
<para>
Le projet <ulink url='http://conglomerate.org/'>Conglomerate</ulink>
vise spécifiquement à fournir un bon éditeur DocBook. Début 2004, ce
programme était toujours en version alpha.
</para>
<para>
Le projet <ulink
url='http://www.freespiders.org/projects/gmlview/'>MlView</ulink> est un
éditeur XML généraliste. Début 2004, il n'était pas assez documenté et
semblait être en version alpha.
</para>
<para>
<ulink url="http://www.lyx.org/">LyX</ulink> est un éditeur de texte
graphique utilisant LaTeX pour l'impression et permettant l'édition
structurelle du balisage LaTeX. Il existe un paquet LaTeX qui produit du
DocBook et un <ulink
url="http://bgu.chez.tiscali.fr/doc/db4lyx/">guide</ulink> qui décrit
comment écrire du SGML et du XML en utilisant LyX.
</para>
<para>
<ulink url="http://idx-getox.idealx.org/">GeTox</ulink>, l'éditeur XML
de GNOME, vise les utilisateurs ayant un profil non technique.
Malheureusement, ce logiciel est toujours en version alpha (depuis
août 2001) et est plus un prototype qu'un outil utilisable. En
outre, l'équipe du projet ne semble pas très active. Le site du projet
n'a pas été mis à jour entre mai 2001 et janvier 2006 (date de
publication de la version française de ce guide).
</para>
<para>
<ulink url="http://www.math.u-psud.fr/~anh/TeXmacs/TeXmacs.html">GNU
TeXMacs</ulink> est un projet d'éditeur adapté à la rédaction de
documents techniques et mathématiques, et permettant l'affichage de
formules. La version 1.0 a été publiée en avril 2002. Les développeurs
prévoient une compatibilité XML à l'avenir, mais celle-ci n'est pas
encore réalisée.
</para>
<para>
<ulink url="http://www.freesoftware.fsf.org/thotbook/">ThotBook</ulink>
est un projet d'éditeur graphique pour DocBook basé sur la boîte à
outils Thot. Il est vraisemblablement moribond car la page web n'a pas
été mise à jour entre novembre 2001 et février 2006 (date de publication
de la version française de ce guide).
</para>
<para>
La plupart des gens continuent à écrire directement les balises à la
main dans vi ou emacs.
</para>
</sect1>
<sect1><title>Trucs et astuces</title>
<para>
Il est possible de produire un index en incluant une balise <sgmltag
class="emptytag">index</sgmltag> vide à l'endroit du document où vous
voulez qu'il apparaisse. Gardez en mémoire que, début 2004, cette
fonctionnalité était toujours assez fruste. Elle ne fusionnait pas les
intervalles et le rendu au format PostScript n'était pas encore d'une
qualité suffisante pour une utilisation sérieuse.
</para>
<para>Cet espace est réservé à d'autres trucs et astuces.</para>
</sect1>
<sect1><title>Pratiques et standards apparentés</title>
<para>
Les outils d'édition et de mise en forme du balisage DocBook sont en
train d'émerger, bien que lentement. Mais DocBook en soi est un moyen et
non une fin. Nous aurons besoin d'autres standards en plus de DocBook
pour atteindre l'objectif de bases de documents interrogeables que j'ai
évoqué au début de ce document. Les deux enjeux principaux sont le
catalogage de document et les méta-données.
</para>
<para>
Le projet <ulink
url="http://scrollkeeper.sourceforge.net/">Scrollkeeper</ulink> a pour
objectif de satisfaire ce besoin. Il fournit des points d'entrées
utilisables par les scripts d'installation et de désinstallation de
paquets pour enregistrer et désenregistrer leurs documentations dans une
base de données commune partagée et interrogeable.
</para>
<para>
Scrollkeeper utilise le format <ulink
url="http://www.ibiblio.org/osrt/omf/">Open Metadata Format</ulink>. Il
s'agit d'un standard d'indexation des documentations libres similaire à
un système de catalogue sur fiche de bibliothèque. L'idée est d'offrir
des fonctionnalités de recherches avancées utilisant aussi bien les
méta-données du catalogue que le texte de la documentation elle-même.
</para>
</sect1>
<sect1 id="sgml"><title>SGML et les outils SGML</title>
<para>
Dans les sections précédentes j'ai laissé de coté une bonne partie de
l'historique de DocBook. XML a un grand frère,
SGML<indexterm>
<primary>SGML</primary>
</indexterm>
ou <foreignphrase lang="en">Standard Generalized Markup
Language</foreignphrase>.
</para>
<para>
Jusqu'en mi-2002, aucune discussion au sujet de DocBook n'aurait été
complète sans une longue excursion dans SGML, les différences entre SGML
et XML et des descriptions détaillées de la chaîne logicielle SGML
DocBook. La vie est désormais plus simple. Une chaîne logicielle XML
DocBook libre est disponible, elle fonctionne aussi bien que ne l'a
jamais fait la chaîne SGML et est beaucoup plus facile à utiliser. Si
vous ne pensez jamais avoir à traiter d'anciens documents SGML DocBook,
vous pouvez sauter la suite de cette section.
</para>
<sect2><title>DocBook SGML</title>
<para>
DocBook était à l'origine une application de SGML et il existait une
chaîne logicielle DocBook basée sur SGML, qui est désormais moribonde.
Il existe des différences mineures entre la DTD DocBook SGML et la DTD
DocBook XML que nous pouvons ignorer ici. La seule qui soit visible par
les utilisateurs est le fait que les balises SGML vides ne nécessitent
pas d'avoir une barre oblique ajoutée avant le > de fermeture (la
barre oblique obligatoire signifie que les analyseurs XML peuvent être
beaucoup plus simples car ils n'ont pas à connaître la DTD pour savoir
quelles balises d'ouverture nécessitent des balises de fermeture).
</para>
<para>
Jusqu'à la version 4.01 (avant XHTML), HTML était une application de
SGML. TEI était à l'origine également une application de SGML. Les
équipes en charge de ces deux DTD sont passées à XML pour la même raison
que les développeurs de DocBook — c'est radicalement plus simple.
SGML était extrêmement complexe et s'est donc avéré impossible à gérer.
La spécification comportait 150 pages très denses et il n'a jamais été
vérifié qu'un logiciel l'ait entièrement mis en œuvre.
</para>
<para>
Le schéma de chaîne logicielle que j'ai donné plus tôt était simplifié
car il montrait uniquement la chaîne XML. Voici la version
historiquement correcte :
</para>
<mediaobject>
<imageobject>
<imagedata fileref="&images;schema-04.png" role="html" format="PNG"/>
</imageobject>
<imageobject>
<imagedata fileref="&images;schema-04.svg" role="fo" format="SVG"/>
</imageobject>
</mediaobject>
<para>
La chaîne logicielle DSSSL servait à traiter le SGML DocBook. Dans cette
chaîne, un document au format DocBook est traité par un des deux moteurs
de feuilles de style (Jade ou OpenJade). Il est ainsi transformé en
balisage de macros TeX qui était convertit en DVI par un paquet appelé
JadeTex pour être finalement transformé en PostScript.
</para>
</sect2>
<sect2><title>Outils SGML</title>
<para>
Le projet <ulink
url="http://sources.redhat.com/docbook-tools/">docbook-tools</ulink>
fournit des outils libres pour convertir du SGML DocBook en HTML,
PostScript et dans d'autres formats. Ce paquet est intégré à la
distribution Red Hat et à d'autres distributions Linux. Il est maintenu
par Mark Galassi.
</para>
<para>
<ulink url="http://www.jclark.com/jade/">Jade</ulink> est un moteur
utilisé pour appliquer des feuilles de style DSSSL à des documents SGML.
Il est maintenu par James Clark.
</para>
<para>
<ulink url="http://openjade.sourceforge.net/">OpenJade</ulink> est un
projet communautaire entrepris parce que ses créateurs pensaient que la
maintenance de Jade réalisée par James Clark n'était pas satisfaisante.
Les programmes de docbook-tools utilisent OpenJade.
</para>
<para>
<ulink
url="http://www.tei-c.org.uk/Software/passivetex/">PassiveTeX</ulink>
est le paquet de macros LaTeX utilisé par
<application>xmlto</application> pour produire du DVI à partir du XML
DocBook. <ulink url="http://jadetex.sourceforge.net/">JadeTex</ulink>
est le paquet de macros LaTeX utilisé par OpenJade pour produire du DVI
à partir du SGML DocBook.
</para>
</sect2>
<sect2><title>Pourquoi le SGML DocBook est mort</title>
<para>
La chaîne logicielle DSSSL, si l'on considère les nouveaux
développements, est, en pratique, morte. La chaîne XSLT a atteint
mi-2002 une qualité suffisante pour les environnements de production.
Une version fonctionnelle de cette chaîne est intégrée à la distribution
Red Hat 7.3. C'est sur cette chaîne que les développeurs DocBook
concentrent la plupart de leurs efforts.
</para>
<para>
La raison du passage à XML est triple. Premièrement, SGML s'est avéré
être trop compliqué à utiliser ; deuxièmement, DSSSL s'est avéré
trop compliqué à appliquer et enfin des parties significatives de la
chaîne DSSSL se sont avérées être fragiles et trop mal conçues.
</para>
<para>
Apparenté à SGML, XML possède un nombre de fonctionnalités réduit, ce
qui est suffisant dans la plupart des cas tout en simplifiant grandement
sa compréhension et la mise en œuvre d'analyseurs. Les outils de
traitement SGML (comme les analyseurs de validation) doivent mettre en
œuvre bon nombre de fonctionnalités non utilisées par DocBook et les
autres systèmes de balisage de textes. Le fait d'enlever ces
fonctionnalités a rendu XML plus simple et les outils de traitement XML
plus rapides.
</para>
<para>
Le langage utilisé pour décrire les DTD SGML est suffisamment épineux et
rébarbatif pour que l'écriture de DTD SGML relève du domaine de la
science occulte. Les DTD XML, d'un autre coté, peuvent être décrites
comme un dialecte d'XML lui-même. Un langage de DTD séparé n'a donc pas
lieu d'être. Une description XML d'une DTD XML est appelée un
<firstterm>schéma</firstterm><indexterm>
<primary>schéma</primary>
</indexterm>.
L'usage du terme DTD lui-même va probablement se perdre au fur et à
mesure de la standardisation des schémas.
</para>
<para>
Cependant la chaîne logicielle DSSSL est surtout morte à cause de DSSSL
lui-même : le langage de description des feuilles de style de SGML
était trop obscur pour la plupart des êtres humains ce qui a rendu les
feuilles de style trop difficiles à écrire et à modifier<footnote><para>
Il s'agissait d'un dialecte de Scheme. Votre humble auteur, adepte de
LISP depuis des lustres, est pris d'effarement à l'idée que cela puisse
en faire fuir certains
</para></footnote>.
</para>
<para>
Les défenseurs d'XML aiment résumer tous ces changements ainsi :
<quote>XML : ça a bon goût et c'est facile à digérer.</quote>
</para>
</sect2>
<sect2><title>SGML-Tools</title>
<para>
SGML-Tools était le nom d'une DTD utilisée par le <ulink
url="http://www.tldp.org">Projet de documentation Linux (LDP)</ulink>,
développée il y a quelques années alors que la chaîne logicielle DocBook
n'existait pas. Le balisage de SGML-Tools était plus simple mais aussi
beaucoup moins souple que DocBook. La chaîne logicielle SGML-Tool
d'origine (outil de mise en forme, DTD et feuilles de style) est morte
depuis déjà un certain temps mais son successeur, appelé <ulink
url="http://sourceforge.net/projects/sgmltools-lite/">SGML-tools
Lite</ulink> est toujours mis à jour.
</para>
<para>
Le Projet de documentation Linux a progressivement abandonné SGML-Tools
au profit de DocBook, mais il est toujours possible que vous ayez à
reprendre de vieux guides pratiques. Ils sont reconnaissables par leur
entête d'identification <quote><!doctype linuxdoc system></quote>.
Si jamais cela vous arrive, convertissez cette chose au format XML
DocBook et enterrez rapidement la vieille version.
</para>
</sect2>
</sect1>
<sect1><title>Références</title>
<para>
Une des choses qui compliquent l'apprentissage de DocBook est le fait
que les sites sur le sujet ont tendance à submerger les débutants de
listes de standards du W3C, d'exercices volumineux sur la théologie du
balisage et de terminologie abstraite.
</para>
<para>
<quote><foreignphrase lang="en"><ulink
url="http://xml.oreilly.com/news/dontlearn_0701.html">Take My Advice:
Don't Learn XML</ulink></foreignphrase></quote> (<quote>Suivez mon
conseil, n'apprenez pas XML</quote>) de Michael Smith sonde le monde
d'XML depuis un angle similaire à celui de ce document.
</para>
<para>
<quote><citetitle><foreignphrase lang="en">DocBook: The Definitive
Guide</foreignphrase></citetitle></quote> Norman Walsh est disponible en
<ulink url="http://www.oreilly.com/catalog/docbook/">version
papier</ulink> et sur le <ulink
url="http://www.docbook.org/tdg/en/html/docbook.html">web</ulink>. C'est
en fait la référence qui fait autorité mais c'est un désastre en tant
que document d'introduction ou d'apprentissage. Lisez plutôt ceci :
</para>
<para>
<quote><foreignphrase lang="en"><ulink
url="http://opensource.bureau-cornavin.com/crash-course/">Writing
Documentation Using DocBook: A Crash
Course</ulink></foreignphrase></quote>. C'est un excellent guide
d'apprentissage.
</para>
<para>
Il existe une excellente <quote><ulink
url="http://www.dpawson.co.uk/docbook/">FAQ DocBook (en
anglais)</ulink></quote> contenant de nombreuses informations sur la
personnalisation du style du HTML produit. Il existe également un <ulink
url="http://docbook.org/wiki/moin.cgi">wiki</ulink> DocBook (en
anglais).
</para>
<para>
Si vous écrivez pour le Projet de documentation Linux, lisez le
<quote><foreignphrase lang="en"><ulink
url="http://www.linuxdoc.org/LDP/LDP-Author-Guide/index.html">LDP Author
Guide</ulink></foreignphrase></quote>.
</para>
<para>
La meilleure introduction à SGML et XML, que j'ai personnellement lue
d'une traite, est celle de David Megginson : <quote><foreignphrase
lang="en"><ulink
url="http://www.amazon.fr/exec/obidos/ASIN/0136422993/171-8635393-7110656">Structuring
XML Documents</ulink></foreignphrase></quote> (Prentice-Hall,
ISBN : 0-13-642299-3).
</para>
<para>
Au sujet d'XML, le livre en anglais <quote><ulink
url="http://oreilly.com/catalog/9780596002923/">XML in a
Nutshell</ulink></quote> de W. Scott Means et Elliotte
<quote>Rusty</quote> Harold, est très bien.
</para>
<para>
<quote><ulink
url="http://www.amazon.fr/exec/obidos/ASIN/274640088X/171-8635393-7110656">XML
guide de l'utilisateur</ulink></quote> semble être un ouvrage de
référence assez approfondi sur XML et les standards associés (dont
notamment Formatting Objects).
</para>
<para>
Enfin, le site <quote><foreignphrase lang="en"><ulink
url="http://xml.coverpages.org/">The XML Cover
Pages</ulink></foreignphrase></quote> vous entraînera dans la jungle des
standards XML, si c'est vraiment ce que vous voulez.
</para>
</sect1>
</article>
