dblatex : Docbook XML -> LaTeX -> PDF

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
22
nov.
2006
Bureautique
La sortie de la version 0.2 de dblatex est l'occasion de présenter ce logiciel relativement méconnu.

Dblatex est un logiciel permettant de convertir un document Docbook en un document LaTeX qui pourra alors être publié en PDF (ou PostScript et DVI).

Contrairement aux autres moteurs de publication traditionnellement associé à Docbook comme FOP ou XEP qui s'appuient essentiellement sur XSL-FO et Java, dblatex s'appuie sur Python, xsltproc et des feuilles XSL pour réaliser la conversion XML->LaTeX et sur un moteur TeX pour la publication.

Dblatex supporte une grande partie de la spécification Docbook et comporte des fonctionnalités peu ou pas supportées par les autres alternatives, par exemple :
Sa grande force réside dans l'interfaçage et l'utilisation de technologies/logiciels standards, portables et éprouvés (Python, xsltproc, LaTeX).
Cela conduit à un logiciel :
  • facile à installer/administrer
  • facile d'utilisation
  • libre
  • portable (*BSD, GNU/Linux, MacOS, Windows)
  • performant (grâce à xsltproc et LaTeX)
  • pérenne (tant que xsltproc et LaTeX seront là...)
  • au rendu très agréable à l'oeil ;-)

D'un côté nous avions LaTeX qui était (est toujours ?) la référence en matière de publication scientifique depuis des années et qui possède un moteur de rendu extrêmement puissant en plus d'un nombre infini de paquets/contributions et de l'autre une technologie très prometteuse pour l'édition de documentations techniques qui sépare enfin proprement le fond et la forme : Docbook.
Dblatex jette enfin un pont entres les deux mondes. Etant utilisateur depuis un petit moment de LaTeX pour sa capacité à traiter les équations, mon avis est sans doute légèrement biaisé. Je pense néanmoins que la publication de document est quelque chose de délicat et qu'il n'est pas du tout facile de créer un programme permettant de pondre de manière 'propre' un document destiné à être imprimé (faire la césure au bon endroit, prendre en compte les caractéristiques de chaque langue, faire une bonne mise en page, etc...).

Pour moi LaTeX reste la référence et je n'ai rien vu qui puisse m'offrir une si belle mise en page. Pour autant j'ai souvent été frustré par la complexité de LaTeX qui nécessite parfois de devoir faire des contorsions inimaginables pour arriver à faire ce que l'on veut (essayer par exemple de mettre de la couleur dans un tableau avec des cellules fusionnées...) et surtout qui requiert un effort surhumain pour séparer convenablement fond et forme.

Etant également un gros producteur de documents scientifiques, j'ai été attiré par XML/Docbook mais ce qui me retenait étaient les limitations actuelles des programmes et donc la peur de ne pouvoir faire exactement ce que je veux.
Les technologies autour de XSL-FO et de FOP ne m'avaient pas convaincu (en plus je n'appréciais que moyennement que l'on soit contraint d'utiliser Java) et j'avais toujours des trucs un peu tordus à faire dans mes documents (comme des équations...).

Dblatex est pour moi la solution idéale : je peux rédiger proprement le fond de mon texte et bénéficier de la mise en page de LaTeX.
La personnalisation se fait au travers de feuilles de style XSL et de code LaTeX. Et si, par hasard, j'ai besoin de quelque chose de vraiment exotique qui n'est pas pris en compte par dblatex je peux toujours insérer des bouts de code LaTeX en 'sous-marin' dans le code XML/Docbook (c'est mal mais ça dépanne).
En plus c'est assez rapide et n'est pas trop gourmand en ressources mémoire et CPU.

Dans le cadre d'une entreprise c'est impeccable : les employés s'occupent de taper leur texte au kilomètre et une seule personne est responsable du style de la mise en page (en-têtes, pied de pages, style des paragraphes, ...).
Et comme dblatex tourne depuis peu impeccablement sous Windows, il n'y a vraiment plus d'excuses pour ne pas l'adopter en entreprise. ;-)
La pérennité est de plus assurée et la prise en compte de nouvelles fonctionnalités relativement rapide. En effet comme LaTeX est déjà capable de faire à peu près tout et n'importe quoi, prendre en compte une nouvelle fonctionnalité se résume à trouver le bon paquet LaTeX et à faire l'interface adéquate (je simplifie beaucoup mais bon l'idée est là).

Dblatex n'est quand même pas parfait, pour ne donner qu'un exemple il n'est pas donné à n'importe qui de pouvoir faire une personnalisation poussée de son document car cela nécessite de maîtriser à la fois les feuilles de style XSL et surtout LaTeX. De plus tout Docbook n'est pas supporté et il subsiste sans doute de nombreux bogues. Cependant son auteur est très sympa et très réactif et à l'écoute des utilisateurs.

En conclusion, j'encourage tout le monde à lui donner une chance et à l'essayer puis... à l'adopter ! ;-)

Aller plus loin

  • # Et LyX ?

    Posté par  . Évalué à 3.

    Je profite d'une dépêche qui parle de LaTeX pour parler de LyX.
    C'est vraiment un excellent logiciel qui permet de produire des documents ms en page par LaTeX sans se fatiguer, avec toujours la possibilité d'insérer du code LaTeX si besoin est, et de retoucher le document en faisant un export LaTeX en cas de problème.

    Il y a même un support DocBook dedans mais j'avoue ne pas avoir testé.

    Seul défaut : la gestion de l'UTF8 qui donne quelque chose d'assez ignoble pour l'interface sur Edgy...

  • # L'union fait la force

    Posté par  . Évalué à 2.

    Le projet de feuilles de style libres qui fait référence en matière DocBook permet déjà la transformation DocBook -> Latex:
    http://wiki.docbook.org/topic/formats

    Pouquoi ne pas rejoindre le projet original?
    http://docbook.sourceforge.net/

    Je ne vois pas l'intérêt de dblatex. On peut déjà se passer de FOP avec le projet référence:

    fichiers en DocBook (XML) ---[xsltproc]---> HTML
    fichiers en DocBook (XML) ---[xsltproc]---> XSLFO -----[FOP/XEP]-----> PDF
    fichiers en DocBook (XML) ---[xsltproc]---> Latex -----[outils latex]---> PDF

    Les feuilles de style XSL du projet référence s'utilisent déjà avec xsltproc. Dans notre dernier cas nous n'avons utilisé aucun programme java pour obtenir du PDF. On pourrait n'utiliser aucun programme java s'il y avait des formatteur XSLFO existant en d'autres langages.

    Note: FOP peu remplacer xsltproc mais est plus lent. FOP a 2 rôles: processeur XSLT et XLSFO. On peu utiliser l'un sans l'autre et c'est ce que je fait.

    • [^] # Re: L'union fait la force

      Posté par  . Évalué à 2.

      La chaîne de traitements:
      fichiers en DocBook (XML) ---[xsltproc]---> XSLFO -----[FOP/XEP]-----> PDF
      pourrait être réalisé sans java s'il existait des formatteurs XSLFO suffisamment abouti dans d'autres langages.

      • [^] # Re: L'union fait la force

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

        Il me semble que xmltex et passivetex mangent directement du XSL-FO pour le tranformer en TeX. D'ailleurs passivetex a été écrit par sebastian rahtz de TEI qui est à l'origine de la distribution TeXLive.

        Personnelemnt, Je me suis amusé à faire des épreuves d'un gros document TEI en LaTeX avec XSLT, c'était plutôt galère à faire (et la syntaxe de XSL-FO m'a clairement fatigué).

        Le top serait effectivement de faire son document en XML, pour pouvoir le manipuler avec tous les bidous XML et d'utiliser TeX pour le formater à la fin.

        Sinon, je ne sais pas trop où en est le projet Oméga (censé être le successeur de TeX, avec des choses très intéressantes comme la possibilité de manger directement de l'UTF-8 ou des fontes OpenType). Mais il prévoyait il me semble une syntaxe XML pouvant être directement utilisée appelé Xlatex :

        http://omega.enstb.org/xlatex/

        Pour moi ce serait limite l'idéal, parce qu'une syntaxe comme Docbook ou TEI serait très facile à transformer avec XSLT en document de type xlatex, à compiler dans Oméga et roulez !

        De toute façon, un gros document en LaTeX est difficile à automatiser complètement, parce qu'il y a toujours des petites saloperies qui apparaissent et qu'il faut corriger problème par problème. Travailler directement en TeX/LaTeX/xlatex est plus pratique que XSL-FO (qui de plus est limité par rapport à ce que les autres peuvent faire)...

        Par ailleurs deux mots sur Yannis Haralambous qui s'occupe d'Oméga, son livre chez O'Reilly Fontes et Codages est merveilleux. Si le sujet vous intéresse vous aurez tout de l'ASCII à l'UTF-8, des fontes PS à OpenType, de la fabrication d'une fonte, sur UNIX/X Window, Mac OSX, Windows, avec de nombreux morceaux de TeX et de METAFONT dedans :

        http://www.oreilly.fr/catalogue/284177273X.html

    • [^] # Re: L'union fait la force

      Posté par  (Mastodon) . Évalué à 0.

      En plus Java est GPL, pourquoi ne pas l'utiliser :-)

    • [^] # Re: L'union fait la force

      Posté par  . Évalué à 3.

      Bonjour,

      Sur la page http://docbook.sourceforge.net/ ils mentionnent dblatex donc je suppose qu'il y a une interaction entre les deux projets (probablement que dblatex s'appuient aussi sur ces feuille de style).

      C'est d'ailleurs la seule alternative mentionnée pour générer du PDF...

  • # lxml support les transformation xslt

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

    A noter qu'il est possible de faire des transformations XSL directement depuis python grace a lxml:

    http://codespeak.net/lxml/api.html#xslt

    lxml est basé sur libxml2/libxslt tout comme xsltproc donc les performances doivent être les mêmes.

    • [^] # Re: lxml support les transformation xslt

      Posté par  . Évalué à 2.

      Oui j'avais posé la même question : pourquoi ne pas utiliser directement la surcouche python ?
      L'auteur m'a répondu que c'était pour garder une interface simple pouvant par la suite ouvrir la voie à l'utilisation d'autres processeurs que xsltproc.
      Donc si certains veulent utiliser leur processeur préféré (Saxon, Xalan, XEP...), il suffit de demander... ;-)

  • # Editeur DocBook

    Posté par  . Évalué à 3.

    Existe-t-il des éditeurs spécifiques à DocBook permettant d'écrire des documents facilement (disons pour un non informaticien qui a besoin de documenter un produit) ou au pire, dans le style de Kile pour LaTeX ?
    Qu'utilisez-vous pour écrire vos documents DocBook ?

    • [^] # Re: Editeur DocBook

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

      Non, pas exactement. Il faut utiliser un éditeur XML, s'il est bien fait il pourra vérifier la syntaxe par rapport à la DTD/Shema/RelaxNG, te permettre la complétion des balises que tu as le droit d'utiliser dans telle balise, et te faire l'indentation.

      L'un des must serait un logiciel proprio appelé <oXygen/>, je l'ai utilisé pour de gros document XML a une époque, il est très sympa, et propose de nombreuses fonctionnalités XML, mais il est plutôt lourd (Javaaaaaa, ton univers simpitoyaaaahablheuuuu).

      Sinon j'utilise Emacs avec PSGML ou NXML (avec lequel on peut choisir directement un schema DocBook), qui offrent moins de fonctionnalités que <oXygen/> mais permettent un résultat correct. (Et oui Emacs prend moins de place en mémoire qu' <oXygen/> :-p)

      • [^] # Re: Editeur DocBook

        Posté par  . Évalué à 2.

        C'est bizarre qu'il n'existe finalement pas de puissant éditeur XML libre (en dehors d'emacs), alors que l'utilisation d'XML est généralisée et qu'il est devenu le symbole des formats libres...
        [J'entends pas éditeur, un logiciel permettant de valider le XML que l'on écrit, d'afficher sa structure pour facilement naviguer dedans et permettant de facilement le modifier]

      • [^] # Re: Editeur DocBook

        Posté par  . Évalué à 2.

        J'utilise également Xemacs avec le mode psgml
        Je regrette simplement que :
        1) nxml ne soit plus maintenu et en particulier qu'il n'évolue plus...
        2) nxml ne soit pas compatible avec Xemacs...

        Bizarre qu'un logiciel aussi populaire que (X)emacs n'inclue pas un mode activement maintenu pour l'édition de document XML.
        Ou bien psgml/nxml suffit amplement, ou bien tout le monde est passé sur vim... ;-)

    • [^] # Re: Editeur DocBook

      Posté par  . Évalué à 2.

      J'utilise XXE : http://www.xmlmind.com/xmleditor/stdedition.html . C'est, je pense, le seul éditeur DocBook digne de se nom. Il nécessite un peu de pratique pour être productif. Dans ses petits plus, il prend en charge la version 5.
      Il y a également Conglomerate (http://www.conglomerate.org) mais le projet est mort.

    • [^] # Re: Editeur DocBook

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

      En entreprise, ce qui est pas mal, c'est de faire des petits assistants du type :
      _ Récuperer l'utilisateur pour charger ses coordonnées sur le LDAP
      _ Chercher le contact dans le LDAP sinon le rajouter
      _ Saisir le corps du texte.
      _ Verification de l'orthographe
      _ Le courrier tout nickel sort sur l'imprimante
      _ La BDD relation clients est mise à jour avec le courrier et la date

      Avantages :
      _ les contacts sont à jour
      _ la bdd clients est à jour
      _ les courriers sont tous pro
      _ tout le monde gagne du temps.


      Ça peut même être mis en bout de chaine d'un workflow
      _ Avec un assistant, le commercial rédige un contrat
      _ Le directeur/juriste/comptable verifie et valide sur l'intranet.
      ..... le prog intervient ici
      _ Le commercial reçois un mail avec le contrat en pièce jointe

      C'est quand même mieux qu'un truc bricolé au pifo-millimètre avec PDF::API2. C'est propre. C'est du LaTex .

    • [^] # Re: Editeur DocBook

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

      J'ai utilisé à une époque epcEdit [1] (commercial). Par contre, ça deviens difficile lorsque le document deviens très gros.

      Il y a aussi Conglomerate [2] - faudrais regarder comment il a évolué (je l'avais regardé rapidement il y a plusieurs années, c'était pas encore ça).

      Il y a un article de 2005 [3] sur NewsForge: "Open source XML editors examined".


      A+

      Laurent.

      [1] http://www.epcedit.com/
      [2] http://conglomerate.org/
      [3] http://programming.newsforge.com/programming/05/02/24/165024(...)

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

  • # écrire du XML

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

    Le XML ne m'a pas l'air d'être un langage pratique en l'écrivant à la main, sauf à utiliser des éditeurs spécialisés. Et j'en sait quelque chose pour écrire mes pages web XHTML à la main.

    Pour l'édition de documents, un jour quelqu'un avait parlé de Tbook¹ qui semble plus adapté pour une utilisation non technique. A mon avis c'est une bonne solution sauf que je n'ai pas envie d'écrire à la main le XML.
    J'envisage d'utiliser une syntaxe à la lisp pour cela. Cela m'a l'air beaucoup plus facile, moins de parenthèses ... et comme j'aimerais pouvoir éventuellement automatiser certaines parties, j'aimerais bien que ce soit un vrai langage de programmation. Il y a bien Skribe² mais le backend XML n'est pas parfait et j'avais du l'adapter (et ce n'est pas encore parfait). C'est pour cela que je préfère créer ma propre solution :)

    ¹ http://tbookdtd.sourceforge.net/
    ² http://www-sop.inria.fr/mimosa/fp/Skribe/

  • # Edition collaborative de docs XML

    Posté par  . Évalué à 3.

    Bonjour,

    Je vois un obstacle à l'utilisation d'éditeurs spécialisés pour le XML, c'est l'édition collaborative de documents par exemple avec subversion. En cas de conflit, le document XML a des chances de ne plus être valide.
    Questions donc:
    - Y a-t-il des éditeurs XML qui gèrent-ils les marquages de conflits dans le document ?
    - Y a-t-il des outils de merge de modifications qui peuvent utiliser une DTD pour proposer un fusion des différences ou un marquage des conflits tout en conservant un document correct ?

    • [^] # Re: Edition collaborative de docs XML

      Posté par  . Évalué à 2.

      Une solution, bien que non satisfaisante, est de vérouiller le document (poser un verrou exclusif en écriture, "reserved check-out") dans le repository.

      Ca existe depuis Subversion 1.2.

    • [^] # Re: Edition collaborative de docs XML

      Posté par  . Évalué à 3.

      D'un autre coté, que ce soit pour un source C, ou DocBook, ou ce que vous voudrez, il est normal qu'un conflit rende le document non valide, car il est essentiel que le conflit soit détecté et traité par un humain.

      • [^] # Re: Edition collaborative de docs XML

        Posté par  . Évalué à 2.

        mais un outil de merge (et de diff) qui comprend la structure d'un document XML pourrait faciliter le travail de l'humain en question.

  • # Aussi, en Perl...

    Posté par  . Évalué à 2.

    IDX-DocBkXML2LaTeX, dont je suis le modeste auteur : http://www.idealx.com/content/view/200/213/lang,en/ Mais le travail de Benoît est beaucoup plus complet que le mien en matière de fonctionnalités. Respects !

Suivre le flux des commentaires

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