ooo2dbk : Générer du DocBook à partir de documents OpenOffice.org

Posté par  . Modéré par rootix.
Étiquettes :
0
7
jan.
2005
Bureautique
Les fichiers d'OpenOffice.org sont en XML. DocBook est un standard XML OASIS de documentation technique.

Plusieurs approches sont possibles pour passer de l'un à l'autre. Indesko a poursuivi le travail d'Eric Bellot (avec son accord) et met ses évolutions à disposition de la communauté.

OOo2DBK permet de créer des documents DocBook au format "article" et "book". Outre les formatages classiques (comme emphasis), l'export gère bibliographie, glossaire, préface, annexes, table des matières, images insérées dans le document (et redimensionnement), metadata à l'aide de champs utilisateurs, bordures de tableaux etc ...

OpenOffice.org, devient ainsi, un éditeur graphique simple à prendre en main pour produire du DocBook XML.

Indesko espère par cette initiative mettre à la portée de tous la production de documents DocBook, leur permettant alors de bénéficier de tous les outils de traitement DocBook.

NdMeR : le format DocBook (que ce soit en XML ou SGML) est un format normalisé par OASIS Open, la même organisation qui travaille à la normalisation du format XML zippé utilisé par la suite OpenOffice.org/StarOffice et prochainement KOffice, la suite bureautique de KDE.

Aller plus loin

  • # Bonne nouvelle... et l'inverse?

    Posté par  . Évalué à 5.

    Pouvoir convertir du sxw en docbook, c'est une excellente nouvelle. Mais quelqu'un connaîtrait il par hasard un outil pour faire la réciproque, i.e. convertir du docbook en format openoffice.org? Si cela existe, Openoffice deviendrait un éditeur docbook très attractif!

    PS : Bonne année à tous!
    • [^] # Re: Bonne nouvelle... et l'inverse?

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

      Eh bien je me pose la même question,
      la seule info que j'ai trouvée à ce sujet (pour l'instant) est
      ce doc
      http://fr.openoffice.org/Documentation/How-to/writer/DocBook15fr.pdf
      qui semble un peu dépassé...
      Je n'ai pas encore testé la méthode décrite dans un OO récent.

      D'ailleurs personnellement, je veux garder des docs au format
      docbook principalement pour pouvoir facilement les gérer en
      configuration avec CVS, ce qui est très simple avec des fichiers
      à un format "ascii" et en particulier XML.

      Si quelqu'un connaissait une méthode pour gérer avec CVS
      les formats OO je serais également preneur.

      J'entends par "gestion CVS" quelquechose qui me permette
      d'utiliser 'cvs diff' éfficacement, i.e. je ne veux pas stocker
      une version binaire (.sxw) à chaque nouvelle version d'un doc.

      • [^] # Re: Bonne nouvelle... et l'inverse?

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

        >Si quelqu'un connaissait une méthode pour gérer avec CVS
        les formats OO je serais également preneur.

        Oh mais c'est très simple !
        il suffit de détarrer les fichiers .sxw.
        tu vois alors le fichier xml, que tu peut comitter dans CVS.
        Car non, le sxw c'est pas un format binaire.
        Pour automatiser cette procedure, je sais pas trop. Faire un script oo_commit et oo_checkout.
        • [^] # Re: Bonne nouvelle... et l'inverse?

          Posté par  . Évalué à 3.

          Cela ne répond que partiellement au besoin :

          +) oui, en revenant à un format non compressé, donc en manipulant directement des fichiers XML, on peut tirer bénéfice du stockage incrémental de CVS. On a donc a priori un gain (espace de stockage) à gérer les versions successives avec CVS (on ne stocke que les diff plutôt que de stocker l'intégralité de chaque release, comme c'est le cas en mode binaire).

          mais

          -) Si on demande quel est le diff entre deux release, la réponse risque fort d'être incompréhensible pour l'utilisateur (cf balises XML dont il ne soupçonne même pas l'existence). Et c'est pourtant la fonctionnalité qui est la plus importante quand on utilise CVS !


          Etant donné l'adoption du format OASIS Open Document (OD) dès la version 2 d'OOo, format qui devrait être commun à d'autres logiciels (KOffice par ex), la pertinence d'un 'diff' pour ce type de document me semble particulièrement forte. Je ne sais pas comment le 'diff' classique fonctionne (mais je constate qu'il fonctionne vraiment bien avec du txt ;->), mais l'intégration des principes de 'diff' dans un parser XML 'connaissant' la structure OpenDocument devrait être possible. Quelqu'un sait-il si des actions en ce sens ont été menées ?

          Dans le même sens, la notion de patch de document OD pourrait être basée soit sur des manips en chaines de caractères, comme c'est le cas avec les fichiers texte, soit sur des fichiers XSLT, puisque les fichiers OD sont en XML Je ne sais pas du tout s'il y a des projets en ce sens.
        • [^] # Re: Bonne nouvelle... et l'inverse?

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

          Il me semble qu'il est possible de définir un CVSWRAPPER qui propose un traitement de fichier lors du 'commit'. Dans ce fichier on peut définir une règle pour décompresser les fichiers .sxw lors du commit et pour les compresser lors du checkout.

          Il suffit maintenant un outils pour comparer on sxw avec un sxw décompresser et le tour est joué.
      • [^] # Re: Bonne nouvelle... et l'inverse?

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

        Sachant que openoffice peut comparer des documents, tu dois pouvoir arriver a faire un openoffice diff sur deux documents.

        Subversion prevoit de pouvoir utiliser des programmes custom pour faire des diff, tu devrait te pencher sur le sujet.
        • [^] # Re: Bonne nouvelle... et l'inverse?

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

          Au niveau du stockage dans le repository (diff au niveau de l'octet), c'est prévu, mais on ne risque pas de voir ça avant longtemps... Au niveau du "svn diff" (diff au niveau des lignes, pour l'utilisateur), c'est peut-être possible dès maintenant avec l'option --diff-cmd. Mais il faut écrire le programme en question...
      • [^] # docbook aussi dans msword ...

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

        Je me suis posé la meme question recemment...

        Quel standard de fichier adopter ...sachant que la contrainte ultime (et de taille) est que le formatage soit nickel sous MSWord ... ?
        (.doc et .rtf ne sont pas la bonne réponse)

        J'ai bien l'impression que docbook est le moins pire quitte a refaire la mise en page...

        A lire tout de meme : http://wiki.docbook.org/topic/OpenOffice

        Je suis pas sur qu'on puisse faire des documents structurés propres avec un editeur wisiwyg ... a moins de basculer dans le mode "voir source" qui est une fonctionalité de ooo et MSword, pouvez vous me confirmer ?

        Aussi docbook sous msword : http://linuxfr.org/~epo/14670.html

        gpg:0x467094BC

    • [^] # Re: Bonne nouvelle... et l'inverse?

      Posté par  . Évalué à 3.

      > convertir du docbook en format openoffice.org?

      C'est standard dans OOo (Fichier -> Ouvrir).
      Ceci dit ça ne gère pas tous les attributs, notament les largeurs de colonne.
  • # OOo2.0 ?

    Posté par  . Évalué à 6.

    Cela concernera également la version 2 d'OpenOffice ? Car le format de fichier change
    • [^] # Re: OOo2.0 ?

      Posté par  . Évalué à 1.

      extrait de doc/TODO.txt :

      - Process the XML generated from the OpenOffice.org 2.x series.

      Un peu de patience, donc ;-)
  • # Quels éditeurs pour DocBook ?

    Posté par  . Évalué à 0.

    Quel sont les meilleurs éditeurs DocBook?

    Il y a XML Mind Editor (http://www.xmlmind.com/xmleditor/(...)). Seul bémol il n'est pas libre mais la version standard est utilisable gratuitement.
    • [^] # Re: Quels éditeurs pour DocBook ?

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

      Seul bémol ? Non non ! C'est sous windows quand même ! Tu pourrais le préciser, car ca fait un choc. :-)
    • [^] # Re: Quels éditeurs pour DocBook ?

      Posté par  . Évalué à 6.

      comme d'hab, il y a aussi Emacs, avec un environement crée par Norman Walsh himself. plus d'infos là : http://nwalsh.com/emacs/docbookide/(...)

      ceci étant dit, ce que je trouve regrettable, c'est que ce n'est pas tellement le nombre d'éditeurs qui manquent. A la limite, n'importe que éditeur de texte peut faire l'affaire. Par contre, les outils pour générer les fichiers (html/ps/...) à partir des fichiers docbooks ne sont que très rarement proposés de base avec les distributions. Je trouve cela regrettable, car pour les distribs qui n'ont pas de système de package qui gère les dépendances tels que apt-get, urpmi ou yum, installer ces outils est une vraie plaie (les machins openjade, puis xslt, puis dssl, puis ... ).
      • [^] # Re: Quels éditeurs pour DocBook ?

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

        Y'a DocMan qui roxe pas mal, tu peux le trouver par ici (pour windows et nux, c'est en Java) :
        http://www.goshaky.com/docman-distfiles/DocMan/(...)
        il a avec lui toutes les feuilles de styles, les DTD, les outils de transfo, bref, tout en 1, et permet de transformer un DocBook en PDF, XHTML, CHM.
        Il a un seul inconvénient : il faut que le document soit au format UTF-8 si on a des accents et surtout il faut que le document soit valide vis-à-vis de la DTD, sinon pan, l'application se suicide sans autre forme d'explication.
      • [^] # Re: Quels éditeurs pour DocBook ?

        Posté par  . Évalué à 4.

        il le dit lui même

        I have no plans for any future work on this package. I have switched to nxml-mode exclusively.
    • [^] # Re: Quels éditeurs pour DocBook ?

      Posté par  . Évalué à -2.

      bémol ? non mais ça va pas la tête ? CAPUSPALIBRE

      SALETÉ DE FREEWARE POUR OUAINDOZE :o
      • [^] # Re: Quels éditeurs pour DocBook ?

        Posté par  . Évalué à 1.

        Ok capucpalibre... Mais c'est le seul éditeur docbook WYSIWIG que j'ai trouvé. Il est plutôt abouti et a le mérite d'exister. Si vous êtes dans mon cas c'est aujourd'hui la meilleur solution.

        Je dois fournir une solution de documentation à des personnes non informaticiennes qui feront des manuels utilisateur.
        • [^] # Re: Quels éditeurs pour DocBook ?

          Posté par  . Évalué à 5.

          La solution proposée dans la news sert justement à ça ! :-)
          • [^] # Re: Quels éditeurs pour DocBook ?

            Posté par  . Évalué à 2.

            ooo2dbk permet de générer du docbook à partir d'ooo. Ca n'en fait pas une solution de collaboration pour éllaborer des documents docbook. Il ne transforme pas ooo en éditeur WYSIWYG pour DocBook. On peut l'utiliser une fois pour transformer un document. On ne peut pas exporter, importer et ainsi de suite car il y aurait trop de pertes. En résumé il faut travailler en format ooo et exporter en DocBook une fois le travail fini. ooo, même avec ooo2dbk, ne permet pas de *travailler* sur des documents DocBook. Il ne peut qu'en généré, ou en importer avec tous les problèmes que celà pose.

            Aujourd'hui il n'y a aucun éditeur WYSIWYG libre pour DocBook. Les meilleurs éditeurs sont XML Mind (http://www.xmlmind.com/xmleditor/(...)) et Serna (http://www.syntext.com/products/serna/index.htm(...)).
      • [^] # Re: Quels éditeurs pour DocBook ?

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

        >SALETÉ DE FREEWARE POUR OUAINDOZE :o

        Mouais, il n'est pas écrit que pour Windows, il y a une version MacOSX et linux cf. http://www.xmlmind.com/xmleditor/download.shtml(...)
    • [^] # Re: Quels éditeurs pour DocBook ?

      Posté par  . Évalué à 0.

      Il y a JAXE aussi en java (libre)

      Par contre c'est pas fini fini et le code est malheureusement sale, pas documenté, en franglais... Je voulais essayer de contribuer un peu mais j'ai rennoncé.

      Projet a surveiller tout de même
    • [^] # Re: Quels éditeurs pour DocBook ?

      Posté par  . Évalué à 0.

      J'utilise "Quanta +" sous KDE
      Ca reste de l'édition pure texte (pas WYSIWYG), mais au moins, quand tu tapes une balise, il a la ferme automatiquement, fait l'autocomplétion et prévoit la liste des balises/tags suivantes possibles etc. Ca évite au moins les fautes de parser lors des conversions html/pdf etc.
    • [^] # Re: Quels éditeurs pour DocBook ?

      Posté par  . Évalué à 4.

      Il y a Morphon que je préfère comme éditeur wysiwyg, gratuit mais non libre :

      http://www.morphon.com/(...)

      Sinon j'avais écris une doc sur docbook il y a quelques temps, avec notamment une liste des éditeurs spécialisés, je l'ai remis en ligne ici :

      http://calandoa.free.fr/web/docbook/(...)

      Je trouve cependant que Docbook est loin d'être un langage parfait. Après l'avoir pas mal utilisé, j'ai souvent rencontré pas mal de problèmes : par exemple les règles pour l'écriture des balises sont très strictes et parfois mal foutues, et les xslt pour faire du html assez mauvais, alors que le langage existe déjà depuis un certain temps.
    • [^] # Re: Quels éditeurs pour DocBook ?

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

      Ben personnellement j'edite le docbook avec [X]emacs et cela
      se passe bien grace au mode sgml qui charge/parse les DTD.

      Sinon j'ai vu récemment [mais pas testé] ça;
      http://www.roxes.com/produkte/xmlwrite.html

      Celà ne me semble pas "libre" [la licence est en allemand...]
      mais disponible "gratuitement" et c'est une appli java 1.4
      donc dispo sous Linux (entre autre bien sur :))
    • [^] # Re: Quels éditeurs pour DocBook ?

      Posté par  . Évalué à 4.

      Bon, apparement, ca n'a été cité nul part... L'un des meilleurs que je connaisse est conglomerate -> http://www.conglomerate.org/(...)
  • # Pourquoi pas mais...

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

    Le problème, c'est que c'est un export plutôt light par rapport à ce que peut gérer docbook.

    Par exemple, comment dans OpenOffice, on dit que tel morceau de phrase c'est un nom de fichier ? un nom de classe ? de méthode ? etc.. (correspondant respectivement aux balises filename, classname methodname etc...)

    Bref, avec openoffice, on ne peut produire que du docbook simplet même si c'est déjà pas si mal.
    • [^] # Re: Pourquoi pas mais...

      Posté par  . Évalué à 3.

      Bref, avec openoffice, on ne peut produire que du docbook simplet même si c'est déjà pas si mal.

      c'est même déjà très bien. Ca peut notamment aider ceux qui ne connaissent pas à se lancer dans le docbook. Car franchement, quand il s'agit ensuite de générer la doc au format html, quel bonheur d'avoir un format qui est celui que l'on trouve pour quasiment toutes les docs linux ;-)
    • [^] # Re: Pourquoi pas mais...

      Posté par  . Évalué à 4.

      Par exemple, comment dans OpenOffice, on dit que tel morceau de phrase c'est un nom de fichier ? un nom de classe ? de méthode ? etc.

      A priori la balise <filename> est supportée, mais pas les balises <classname> et <methodname>. La liste des balises supportées est disponible ici : http://www.chez.com/ebellot/ooo2sdbk/doc-conversion/ar01s10.htm(...)

      Etant donné que le mécanisme est en place pour certaines balises, je suppose que ça ne doit pas forcément être trop complexe d'ajouter le support pour d'autres balises.

      Sinon, pour générer les balises, il faut à priori utiliser les styles d'OpenOffice.org, voir la documentation de OOo2sDbk à ce sujet :
      http://www.chez.com/ebellot/ooo2sdbk/doc-conversion/index.htm(...)
      • [^] # Re: Pourquoi pas mais...

        Posté par  . Évalué à 3.

        Est-ce qu'une feuille de stype calquée sur les balises DocBook ne ferait pas l'affaire ?

        Hop je sélectionne toto.txt et je lui applique le style "Nom de fichier".

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Pourquoi pas mais...

          Posté par  . Évalué à 2.

          Oui c'est comme ça que ça fonctionne. Un modèle OpenOffice.org adapté à DocBook est inclut dans le package. Il faut faire attention à la différence Style de Caractère et Style de Paragraphe (exemple : paragraphe en Text Body et toto.txt en Filename).
      • [^] # Re: Pourquoi pas mais...

        Posté par  . Évalué à 3.

        Hum, je me suis un peu troué. En fait les liens que je donnais concernent une version antérieure de l'application (ooo2sdbk). La doc (enfin le README) pour la version dont il est question dans la dépêche est disponible ici : http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/Indesko/ooo2dbk/(...)

        D'ailleurs, ce serait peut-être pas mal de remplacer le 1er lien de la dépêche par celui-ci : http://www.indesko.com/sites/fr/telechargements/ooo2dbk___du_docboo(...) car le lien original fournit une version tronquée du texte sans les liens vers les sources et les caractéristiques de l'application.
  • # Gnii ?

    Posté par  . Évalué à 2.

    Suis-je le seul à ne pas comprendre le sens de la phrase "... la même organisation qui est en cours de normalisation du format XML zippé ...". Désolé mais cette phrase, même si elle est écrite en français, n'est pas française du tout.
    • [^] # Re: Gnii ?

      Posté par  . Évalué à 4.

      Ca veut dire que ce sont les mêmes gens qui s'occupent de formaliser DocBook et le format de stockage d'OOo.

      Des parenthèses ou des tirets auraient peut être été plus adaptés que les virgules mais à ce choix typographique près la phrase est tout à fait française et tout à fait compréhensible.

      BeOS le faisait il y a 20 ans !

    • [^] # Re: Gnii ?

      Posté par  . Évalué à 5.

      la même organisation qui est également en train de valider en tant que norme le format de fichier XML compressé (en zip) d'OOo.
  • # attaquons les choses sérieuses

    Posté par  . Évalué à -1.

  • # LaTeX

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

    Je ne gère pas trop ce sujet.

    Tout ce que je sais c'est que LaTeX permet de générer des documents avec les même "parties"...
    Mais les histoires de standards, là je me pose des questions.
    Et puis LaTeX c'est pas du XML.

    Quelles sont les différences ?
    Me trompe-je totalement ?

    Globalement, mon prochain rapport (de stage ou autre) je le rédige en LaTeX ou je passe à autre chose (c'est toujours une occasion de découvrir...) ?

    Merci pour vos lumières...
    • [^] # Re: LaTeX

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

      En gros l'idée de DocBook est de proposé une syntaxe XML mais aussi de proposer le concept qui consiste à séparer la présentation du contenu encore plus loin : il n'y a aucune possibilité de formatage dans la syntaxe DocBook, contrairement à LaTeX : donc pour les puristes c'est mieux.
      Après faut aussi voir le nombre d'outils dispo, etc.
      Reste que c'est du XML, donc facilement manipulable (et aussi facile à générer).
      • [^] # Re: LaTeX

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

        Ah ouais, donc c'est encore ces jeunes qui font ch$$r avec leur manie de créer du neuf qui fait pas mieux que le vieux ;)

        Merci pour ton explication.
      • [^] # Re: LaTeX

        Posté par  . Évalué à 0.

        il n'y a aucune possibilité de formatage dans la syntaxe DocBook


        Si si, c'est possible avec la balise emphasis

        par exemple,
        emphasis role="strong" met les caractères en gras.
        • [^] # Re: LaTeX

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

          Non non tu es tombé dans le piège :)
          La balise emphasis indique qu'il faut mettre en évidence ce qu'il y a au milieu. L'attribut "strong" ajoute une "force" supplémentaire : en gros "met BIEN en évidence ce truc". Effectivement certaines feuilles de styles (dont celles de Norman) interprête celà comme le fait de mettre en italique ou en gras (parcqu'ils ont décidé de représenter ces balises avec ce style), mais tu ne peux absolument pas en déduire que ce sera toujours en gras.
    • [^] # Re: LaTeX

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

      J'ai eu fait mes rapports avec "Latex" (via Lyx) et depuis une fois avec docbook (à la main). LaTeX intègre trop de mise en forme à mon goût, dans un autre côté j'ai eu beaucoup de peine à modifier l'apparence ma sortie pdf du docbook.

      En tant que presque puriste, j'opte pour docbook et m'amuse à écrire mes feuilles xsl qui me ponderont des xsl-fo à mon goût. mais c'est un travail.

      Un des grands avantages de OOo2dbk est qu'il peut tout à fait s'intègrer dans un framework/outil de publication web travaillant avec du docbook lui.
      • [^] # Re: LaTeX

        Posté par  . Évalué à 3.

        C'est un peu ce que fait ServOO : c'est un service web qui prend en entrée un document lisible par OOo (fichier OOWriter ou MS Word par exemple), le passe à tout un tas de moulinettes XML et fait ressortir un document prêt à être inséré dans un CMS.

        Ca marche très bien avec le CMS Lodel (ServOO a été créé pour) et c'est vraiment bien de pouvoir dire à des rédacteurs qu'ils peuvent bosser tranquilement avec leur outil favori sans avoir à apprendre à se servir des éditeurs en ligne.

        http://www.servoo.net/(...)

        BeOS le faisait il y a 20 ans !

    • [^] # Re: LaTeX

      Posté par  . Évalué à 2.

      A propos de LaTeX, quelqu'un connait-il une intégration fructueuse des équations Latex dans oowriter ou ooimpress (l'éditeur d'équation est trop moche pour moi) ?

      Pour PowerPoint et Word, il existe un outil sympa nommé TexPoint (http://raw.cs.berkeley.edu/texpoint/(...)) qui permet au sein de PP (et de Word) d'entrer des équations LaTeX, d'en obtenir une image, de rééditer l'équation au besoin et tout se réalise de manière transparente.

      En clair, TexPoint utilise au distrib latex et du VisualBasic macroifier pour l'interaction. Je suis sûr que les choses seraient encore plus simples à implémenter dans les macro OO.

      Jack
    • [^] # Re: LaTeX

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

      LaTeX est très bien mais en même temps mélange le fond et la forme. Aussi je ne lui vois pas d'avenir face au XML, en particulier celui qui suit la DTD docbook.
      Je pense qu'il va falloit transformer tous les documents LaTeX en XML pour en garantir leur pérennité.
      • [^] # Re: LaTeX

        Posté par  . Évalué à 4.

        Je suis d'accord sur le fait que le LaTex a du souci à se faire concernant sa pérénité. Mais je suis ne pas d'accord pour l'abandonner entièrement. Pour l'instant je ne connais rien de mieux pour faire des rapports propres, ou même des devoirs, principalement les devoirs de maths.

        Je ne sais plus ou j'avais vu ça, surement sur OpenWeb, mais essaye de formater en DocBook (donc en XML), une intégrale avec des trucs bien bizarres dedans (fractions, exposants, sommes, suites, ...) : le rapport mise en forme / données tend vers l'infini avec DocBook ...

        Les formules et l'extrême respect de la typographie disponibles dans LaTeX en font pour moi un élément de référence concernant les rapports, articles ou sujets de maths.

        Par contre, pour ce qui est de la documentation, la, aucun doute, je me tourne vers DocBook.

        - Sam
        • [^] # Re: LaTeX

          Posté par  . Évalué à 3.

          Je suis tout à fait d'accord avec toi, faisant un master de Maths en plus de l'info, je pense être bien placé pour dire que si l'informaticien pense que le XML c'est génial, la matheux ne voit pas d'égale à LaTeX pour ses équations mathématiques...d'ailleurs pourquoi faudrait-il qu'une technologie domine toutes les autres? Il faut des technologies adaptées à ce que l'on veut faire, et LaTeX fait partie de celles-là, longue vie à lui!!!
          • [^] # Re: LaTeX

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

            J'avais peur de déclencher un gros troll et vous me rassurez ;-)

            Toutefois pour les mathématiques, il y a aussi TeXmacs http://www.texmacs.org/(...) créé par Joris Van der Hoeven, lui même chercheur en mathématiques à l'Université Paris-Sud à Orsay.
      • [^] # Re: LaTeX

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

        Je pense que ceux qui disent que LaTeX n'a pas d'avenir se trompent et ne l'on utilisé que pour des besoins très simples pour lesquels docbook suffit.
        Je rappel que LaTeX est capable de faire des équations mathématiques, des schémas (toute sorte de shémas classiques mais aussi plus spécifiquent aux sciences comme les diagrammes de Feynman ou les schémas électroniques), des diagrammes, déssiner des molécules, tracer des courbes, on peut aussi créer des QCM en faisant en sorte que les réponses aux questions soient ordonnées alléatoirement, et bien plus encore...

        Pour bien des choses LaTeX reste sans équivalent. Et personellement, je trouve qu'il est plus facile (moins pénible) d'éditer à la main du code LaTeX que du XML. Reste le dernier point fort de LaTeX : le rendu qui reste irréprochable
        • [^] # Re: LaTeX

          Posté par  . Évalué à 9.

          L'avenir de LaTeX est compromis dans le sens où il n'évolue plus et je dirais même qu'il ne peut plus évoluer (cf. la mort silencieuse du projet LaTeX3).

          Utiliser les différentes classes LaTeX et faire trois/quatre macros, ça va. Mais si on veut aller plus loin (comme créer ses classes ou modifier quelques comportements), ça devient vite compliqué, et ce pour plusieurs raisons :

          1. TeX est un langage de macro, il a des fonctionnalités limités :
          - les commandes de manipulation de fichiers sont extrêmement limitées ;
          - manipuler, donc découper, un par un les caractères d'un mot ou les mots d'une phrase, c'est la croix et la bannière, surtout si l'on veut que ces caractères/mots soient eux-mêmes créés/modifiés (p.ex. : \escalier{mot} qui augmente la taille des caractères du mot à chaque caractère et qui fonctionne aussi bien avec un mot comme « abcd » que comme « \suite{a}{d} » ou simplement « a\^{t}\k{e}\d »)
          - et, en général, les boucles, c'est pas évident (possible : récursivité, mais très compliqué : multiplication de macros intermédiaires).

          2. pour des raisons de compatibilité avec plain TeX, ou tout bonnement de simplicité, le code des paquets LaTeX sont souvent difficilement lisibles...

          P.ex. Knuth écrit " \z@ " à la place de " 0pt " parce que c'est plus rapide à lire pour le moteur de TeX (sic). Bon, avec les PC actuels je doute que cela fasse une grosse différence (même si la proportion est toujours la même, disons p.ex. x1/4, le temps de base est largement moindre : une compilation de 20s avec du code humainement plus lisible ou de 5s avec du moins lisible, ce n'est plus comparable avec 4h de compilation contre 1h...), mais tout le monde continue à écrire du code comme ça.
          Sans parler de la gestion des espaces qui fait que (même si c'est évitable) tout le code est toujours tassé sur une seule ligne ou coupé sans rapport avec la structure logique.

          3. ...et utilisent souvent des macros « internes » de LaTeX et des autres paquets (celles avec un @ dedans)

          P.ex. on modifie la commande de base \truc mais ça ne modifie pas la commande \machin qui est censée l'utiliser parce qu'en fait le corps de \truc est réalisé par \@truc et la commande \machin utilise directement \@truc et non pas \truc. Vous me direz qu'il suffit de modifier \@truc. Mais le problème, c'est que la commande \bidule, du même paquet que \truc, utilise aussi \@truc, et qu'on ne veut pas que \bidule soit modifiée, elle. Donc est obligé de modifier \truc et \machin.

          4. Mélange du contenu et de la forme...

          LaTeX 3 devait permettre de régler une bonne part de tout ça... paix à son âme.
          D'autres projets ont aussi essayé (p.ex. PolyTeX mais il y en d'autres dont j'ai oublié le nom), sans grand succès, peut-être à cause de la quantité de paquets (La)TeX disponibles et de leur réutilisation difficile.

          Mais bon, pour ma part j'utilise toujours LaTeX (j'ai beaucoup de mal à utiliser les « interfaces intuitives » (sic) aussi facilement), et je pense que le moteur TeX est toujours compétitif vis à vis du rendu. Par contre, une petite couche (XML ou autre d'ailleurs) par dessus, ça me semble une très bonne idée.
          • [^] # Re: LaTeX

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

            Merci d'avoir rédigé ce commentaire très pertinent, en vérité c'est celui que j'attendais. Il me permet de conforter mon opinion et surtout de l'étayer. Merci encore.
          • [^] # Re: LaTeX

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

            Je comprend parfaitement ton raisonnement et je le respect. Le seul point sur lequel je suis en mesure de répondre est quand tu dis qu'il ne peut plus évoluer et que cela signifie sa mort lente. LaTeX n'évolue plus car il a est considéré par son auteur comme ayant rempli tous les objectifs qu'il devait remplir. En d'autre terme il y a une catégorie d'utilisateur pour lesquels LaTeX fait exactement ce qu'ils attendent de lui, et n'arrivent pas à trouver de remplaçant (cf mon post plus haut). LaTeX n'évolue plus depuis plus de dix ans ce qui pour toi signifie sa mort lente mais pour d'autres signifie une stabilité. Je sais que si j'ai appris le LaTeX il y a 10 ans aujourd'hui rien n'a changé. Je n'est pas à apprendre la nouvelle syntaxe de la dernière version parce que la moitié de ce que je connais est devenu obsolète.
            • [^] # Re: LaTeX

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

              > LaTeX n'évolue plus car il a est considéré par son auteur comme ayant rempli tous les objectifs qu'il devait remplir.

              Hum. LaTeX 3 est toujours en cours de préparation.
              TeTex n'évolue que très peu, certes, mais c'est parce qu'il n'y a que très peu de bug. Après les surcouches évoluent pas mal.

              De nouveaux packages pour LaTeX sont créés en permanence, donc la syntaxe évolue belle et bien. LaTeX n'est pas le passé, mais plutôt l'avenir. Le problème est qu'il est trop en avance sur le niveau moyen des utilisateurs et des programmeurs.
            • [^] # Re: LaTeX

              Posté par  . Évalué à 4.

              Je n'ai pas dit que le fait que LaTeX n'évoluait pas signifiait sa « mort lente » : les propos précédents parlaient de la possibilité d'un « avenir » pour LaTeX, je voulais surtout dire que (La)TeX n'avait pas véritablement d'avenir dans le sens où, techniquement, il ne progressera plus. Si l'avenir ne diffère pas du présent, est-ce un avenir ?

              La stabilité a du bon mais il faut admettre que (La)TeX a des imperfections quelque peu frustrantes. Mais, et la remarque finale de mon précédent message tentait de le souligner, (La)TeX est effectivement très puissant et irremplaçable pour certaines tâches.

              En fait, pour prendre une image de recherche opérationnelle (j'aime bien voir cela comme une bille sur une surface bosselée), (La)TeX a atteint un optimum local (la bille est au fond d'une vallée) et, pour s'approcher de l'optimal (peut-être est-ce d'ailleurs un optimal qui suit d'autres critères : comme l'utilisabilité par des non-informaticiens, voire des non-scientifiques, peut-être même des < placez ici votre catégorie souffre-douleur favorite ;o) >), il faudrait que la bille franchisse les collines environnantes pour se diriger vers une autre vallée. Mais les collines sont hautes et la vallée éloignée, trop éloignée pour que la bille s'appelle encore (La)TeX.

              Donc, laissons la bille où elle est (bien au chaud), elle y est très utile. (J'oserai ajouter : n'essayons pas de nous persuader qu'il n'y pas de vallée plus intéressante.) Ça ne nous empêche pas de jouer avec d'autres billes (comme XML).
            • [^] # Re: LaTeX

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

              Bon allez moi aussi je vais me lancer dans le débat :
              DocBook a tous les avantages de LaTeX : une syntaxe orientée contenu, le support des formules mathématiques avancé (MathML). Il a même plus : 100% orienté contenu, pas de notion de présentation, 100% XML donc facilement manipulable (question de pérénité) et extensible (cf MathML, SVG et j'en passe), bref il est techniquement mieux que LaTeX qui n'a plus beaucoup d'argument à faire valoir.
              Reste que le format DocBook n'a pas encore de feuilles XSLT avec un rendu impécable (bien que le travail de Norman soit extraordinaire), et surtout il n'a pas le passif de LaTeX, le nombre d'utilisateurs.
              De plus l'absence totale de possibilité de mise en forme dans le document en rebutte plus d'un (bien que ça soit à mon goût indispensable).
              Bref tout ça pour dire que LaTeX a encore de nombreux jours devant lui, même si je crois à terme à sa disparition, parcque le format DocBook a beaucoup plus d'avenir : son format XML et l'absence totale de notion de mise forme laisse supposer de nombreuses possibilités de transformations/conversions vers d'autres formats (dont LaTeX, perso je l'utilise pour la mise en forme) : c'est un format idéal pour concevoir ses documents en se penchant exclusivement sur le contenu : après c'est du XML on peut le transofrmer en n'importe quoi pour la présentation.
              • [^] # Re: LaTeX

                Posté par  . Évalué à 5.

                DocBook a tous les avantages de LaTeX : une syntaxe orientée contenu, le support des formules mathématiques avancé (MathML). Il a même plus : 100% orienté contenu, pas de notion de présentation, 100% XML donc facilement manipulable (question de pérénité) et extensible (cf MathML, SVG et j'en passe), bref il est techniquement mieux que LaTeX qui n'a plus beaucoup d'argument à faire valoir.

                Ce qui fait la force de LaTeX c'est la puissance, la richesse et la facilité qu'il offre pour tout ce qui est équation. C'est l'immense bibliothèque d'extensions que l'on trouve sur CTAN. C'est enfin PSTricks et MetaPost qui permettent de faire des schémas, graphiques très complexes.

                Face à ça qu'offre DocBook ? La question est sincère, je ne connais pas bien.

                MathML ou du moins ce que j'en ai vu, c'est inutilisable manuellement ce qui signifie qu'il faut utiliser un éditeur d'équations à la Word. Rien que ça est rédhibitoire si un document comporte plus de quelques équations.

                Pour ce qui est de la pérennité, depuis le temps que LaTeX existe, il n'a pas vraiment de problème de ce côté là.

                Quant au 100%, c'est de l'argument marketing ou du fantasme d'informaticien ! Peu importe qu'un langage soit chimiquement pur l'important c'est ce qu'il me permet de faire.

                Enfin, il ne faut pas oublier le poids du passé. Utiliser LaTeX, ça représente un investissement en temps. Tout refaire en DocBook ? Il faudrait vraiment que ce format présente des avantages sérieux.
                • [^] # Re: LaTeX

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

                  Face à ça qu'offre DocBook ?

                  XML permet d'inclure tout ce qu'on veut : des images ou du SVG par exemple. Ce qu'il y a de bien avec le SVG, c'est qu'il est normalisé.
                • [^] # Re: LaTeX

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

                  MathML ou du moins ce que j'en ai vu, c'est inutilisable manuellement ce qui signifie qu'il faut utiliser un éditeur d'équations à la Word. Rien que ça est rédhibitoire si un document comporte plus de quelques équations.

                  Je suis bien d'accord. LaTeX est excellent pour les équations car le rendu est irréprochable (comparé à ce que peut faire Word ou même openoffice qui des fois affichent les équations de façon pas très élégante), mais en plus on met moins de temps à les écrire en LaTeX qu'avec un éditeur d'équations "classique".
                  • [^] # Re: LaTeX

                    Posté par  . Évalué à 3.

                    mais en plus on met moins de temps à les écrire en LaTeX qu'avec un éditeur d'équations "classique"

                    Exactement !!
                    Le truc qui serait 'achement bien, pour qu'Openoffice prenne complétement son envol dans la communauté scientifique des "sciences avec des équations", ce serait un mode équation avec édition à la LaTeX et surtout rendu à la LaTeX.
                    Surtout pour les présentations. Il pourrait ainsi concurrencer KeyNote (d'Apple) qui est vraiment bluffant de ce côté là.
                • [^] # Re: LaTeX

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

                  Peu importe qu'un langage soit chimiquement pur l'important c'est ce qu'il me permet de faire.
                  Ben justement, si je peux me dire : "le contenu est séparé de la mise en forme" je peux faire pleins de supposition lorsque je vais manipuler mon document. Si c'était vrai à seulement "95%" ben j'aurai pleins de possibilités en moins parcque je pourrais toujours tomber éventuellement sur un problème/incohérence.
                  L'informatique c'est 0 ou 1, c'est pas entre les 2, alors que LaTeX ne fasse pas clairement la séparation n'est pas torp un gros problème pour l'humain (il peut clairement séparer s'il veut), pour une machine qui va manipuler le document, elle a absoluement besoin de savoir si c'est 0 ou 1.
                  Alors non ce n'est pas commercial.

                  Sinon effectivement DocBook offre moins de bibliothèques que LaTeX, parcque LaTeX ca fait un bail que ca existe et que c'est utilisé. Moi ce que j'ai voulu expliquer c'est qu'il y en a un qui est mieux et qui techniquement plus avancé. Si on se contentait perpétuellement de s'acharner avec les vieilleries qui ont 10000 bibliothèques parcque pleins d'utilisateurs, on serait tous en train de programmer en Fortran.
                  • [^] # Re: LaTeX

                    Posté par  . Évalué à 2.

                    elle a absoluement besoin de savoir si c'est 0 ou 1
                    Et la logique floue alors ? :P

                    http://en.wikipedia.org/wiki/Fuzzy_logic(...)
                    http://fr.wikipedia.org/wiki/Logique_floue(...)
                  • [^] # Re: LaTeX

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

                    Je vais commencé par traité un exemple. Quand tu génères ton document avec LaTeX, il gère tout seul la coupure des mots, des phrases, des paragraphes... (et là on se dit : "c'est formidable !"). Oui mais voilà, des fois la coupure n'est pas esthétique, et bien LaTeX t'offre la possibilité de forcer la main en lui disant où couper ta phrase ou ton paragraphe. Voici un exemple concret dans lequel le fait de mélanger le contenu de la mise en forme est un plus. ça te permet de peaufiner.

                    Si on se contentait perpétuellement de s'acharner avec les vieilleries qui ont 10000 bibliothèques parce que pleins d'utilisateurs, on serait tous en train de programmer en Fortran.
                    Re-exemple. Au risque de choquer certain, je programme toujours en Fortran. Je dirais même que j'ai d'abords appris le C puis le fortran. Peut être que le fortran c'est pas le top du top du langage, mais dans certains domaines comme la simulation, où on a besoin de performances, et bien le fortran c'est le mieux. Car, y a pas mieux pour gérer des matrices (et dieux sait qu'on ne fait que ça pratiquement quand on fait de la simulation), tu n'as pas besoins retoucher ton code quand tu veux faire tourner ton programme en parallèle, contrairement à certains langages, une simple recompilation suffit, et dernier détail, et vu l'histoire du fortran et la manière dont il a été construit (c'est à dire standardisé dès le départ), les compilateurs savent exactement ce que tu veux faire quand tu écris du code. Du coup les compilateurs optimisent un maximum ton binaire.

                    C'est juste pour dire que c'est pas parce que quelque chose est théoriquement mieux qu'il est le plus adapté dans tous les cas. Je suis d'accord pour dire que le XML c'est très bien, et que théoriquement ça pousse le concept de séparer le contenu de la mise en forme jusqu'au bout. C'est donc tout à fait adapté lorsque, par exemple, on génère des documents à partir d'informations qui sont stockées dans une base de données Tout ce qui permet de générer automatiquement un document. Mais moi je suis pas une base de données et je ne suis pas un script qu'on exécute. J'ai des mimines avec lesquels je tape moi même (si si) mes documents.
                    • [^] # Re: LaTeX

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

                      Je suis d'accord pour dire que le XML c'est très bien, et que théoriquement ça pousse le concept de séparer le contenu de la mise en forme jusqu'au bout. C
                      Attention tout de même, ce n'ai pas du tout le fait que ça soit du XML qu'il y a une séparation nette entre contenu et mise en forme : c'est un choix complètement distinct, on peut très bien imaginer un format DocBook XML avec des informations de présentation à l'intérieur.

                      Sinon je suis d'accord avec toi, il y a des cas où le Fortran n'a pas pas d'équivalent niveau puissance, et que le fait de pouvoir ajouter des info de présentation dans un document peut avoir des intérêts. Reste que même si LaTeX ou Fortran ne sont pas prêt de mourrir, il y a pleins de types de programmes/documents qui pourront se passer de ces formats/langages pour des noueaux trucs plus "Haïpe" ou tout du moins plus clean.
                      Moi par exemple je transforme généralement mes trucs XML en LaTeX pour obtenir le rendu final pour utiliser la puissance du moteur de rendu de LaTeX, mais j'utilise alors LaTeX comme une "feuille de style", plus vraiment pour ce à quoi il était destiné, il passe un peu en "annexe". N'oublions pas également que LaTeX a un gros désavantage : il est bien pour générer un document destiné à l'impression, mais dès que c'est pour faire autre chose...
                      • [^] # Re: LaTeX

                        Posté par  . Évalué à 2.

                        Reste que même si LaTeX ou Fortran ne sont pas prêt de mourrir, il y a pleins de types de programmes/documents qui pourront se passer de ces formats/langages pour des noueaux trucs plus "Haïpe" ou tout du moins plus clean.

                        Crois-tu que LaTeX soit encore beaucoup utilisé là où on pourrait utiliser autre chose de mieux et de plus adapté ?

                        J'ai un peu le sentiment que l'utilisation de LaTeX est maintenant réduite aux domaines dans lesquels il excelle (publications scientifiques) et d'où il sera difficile de le déloger ! Pour le reste, les traitements de texte l'ont remplacé car beaucoup plus simples à utiliser.
                        • [^] # Re: LaTeX

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

                          Ben perso je ne connais pas beaucoup d'autres domaines que le mien : l'informatique. Pourtant il y a toujours qui aiment faire leurs rapports en LaTeX. Voir même certains profs (scientifiques donc à la fac) qui exigent.
        • [^] # Re: LaTeX

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

          Voila donc un commentaire que j'apprécie, mais je poursuis mon débat d'opinion au risque de déclencher un gros troll.
          On peut générer du LaTeX à partir de XML (Voir http://db2latex.sourceforge.net/(...) ) si on veut profiter du moteur de rendu de LaTeX. Le XML ne contient aucune indication sur la présentation. Il sépare strictement la forme du contenu ce que ne fait pas LaTeX. La présence d'un bon moteur de rendu n'est pas la preuve d'une bonne syntaxe.
          D'autre part, LaTex peut être comparé à une seule DTD (Docbook est une DTD, c'est à dire une grammaire) alors que le XML peut être réalisé avec un grand nombre de DTD (ou mieux XMLschema).
          Un texte intéressant sur les conversions : http://www.cse.ohio-state.edu/~gurari/docs/mml-00/mml-00.html(...) traite de la réversibilité de la conversion.
          Mon impression est que le XML est une étape importante dans la maturité de la documentation alors que LaTeX ne faisait que répondre à un besoin immédiat quand il a été créé. D'autre part, des éditeurs très puissants permettent d'écrire du XML Docbook sans douleurs (emacs, Lyx, OOo) alors que je ne connais pas d'aides analogues pour LaTeX.
          • [^] # Re: LaTeX

            Posté par  . Évalué à 1.

            bah Lyx justement....
            • [^] # Re: LaTeX

              Posté par  . Évalué à 1.

              Tout-à-fait,
              également Texmacs déjà mentionné précedemment.
              Dans le monde Windows il y a aussi Scientific Word et
              Scientific Work Place.
              Ces deux derniers comme Lyx ne sont pas complètement wyswyg contrairement à Texmacs qui permet également d'exporter en latex html ps pdf.
  • # XSLT

    Posté par  . Évalué à 4.

    Si le format de OpenOffice.org c'est du XML, qu'est-ce qui nous empêche de faire du XSLT pour le transformer en DocBook ?
    A part le fait que ca soit directement intégré à OO.org, un XSLT fait une bonne fois pour toutes pour passer du format SXW au DocBook, et le tour est joué.

    Non ? Je me tant que ça le doigt dans l'oeil ?
    • [^] # Re: XSLT

      Posté par  . Évalué à 6.

      Le problemet c'est que les deux formats ne stockent pas forcement les memes informations. Dans chacun des cas, il peut y avoir un manque d'information semantique. Lit plus haut a propos des noms de classes. Si OpenOffice, dans son format XML, ne fournit pas l'information "Ceci est une classe", tu (ou du moins ta feuille de style) ne peut pas creer automatiquement la balise docbook idoine.

      En gros, tu pourras surement obtenir quelque chose de valide, respectant la DTD Docbook. Mais un puriste Docbook te diras qu'il manque un certain nombre de balises semantiques dans ton document.
    • [^] # Re: XSLT

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

      > Non ? Je me tant que ça le doigt dans l'oeil ?
      Non, mais tout dépend du rapport simplicité d'utilisation/puissance de XSLT, et de sa souplesse.

      Personnellement je préfère 1000 fois les interfaces programmatiques type SAX à des transformations plutôt "descriptives" faites avec XSLT. C'est peut-être une déformation de programmeur, mais bon... J'ai quand même l'impression qu'un bon petit script Python qui utilise SAX pour parser le source XML c'est souvent aussi simple à faire et parfois même plus clair qu'une feuille XSLT qui atteint vite ses limites lorsqu'on essaye de faire générer des formats très variés genre du LaTeX ou des pages man mangeables par groff...
      • [^] # Re: XSLT

        Posté par  . Évalué à 3.

        Mouais... Je suis d'accord avec tes exemples, mais les deux que tu proposes c'est a propos de l'utilisation de XSLT pour produire des documents non XML. Or la on reste dans le cadre traduction XML vers XML.

        Perso, la limite que je vois avec XSLT dans le cadre d'un traitement XML vers XML, est le fait qu'il travaille sur un document source complet. Tres limite lorsque l'on doit travailler avec des documents XML assez enorme. SAX devient tres utile car on travaille sur un flux. Mais le gain n'est valable que si le traitement que l'on effectue se fait sur un flux lui-meme.
    • [^] # Re: XSLT

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

      Le projet ooo2dbk n'ai rien d'autre qu'un script XSLT et un module python :

      $ ls **/*.xsl
      ooo2sdbk/ooo2sdbk.xsl
      $ wc -l ooo2sdbk/ooo2sdbk.xsl
      2565 ooo2sdbk/ooo2sdbk.xsl

      Le code est assez impressionnant ;0)

    • [^] # Re: XSLT

      Posté par  . Évalué à 4.

      OOo2DBK et OOo2sDBK (l'ancienne) ne sont justement rien d'autre que des feuilles XSLT. Le script Python sert essentiellement à deux choses que le XSLT ne permet pas :
      - dézipper le document SXW pour disposer des document XML d'OOo
      - extraire les images, si il y en a, et leur donner un nom (img01, img02, etc) pour qu'elles soient diponibles dans le document Docbook.
  • # Debian

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

    Et déjà un paquet debian en cours de préparation ;-)

    http://lists.debian.org/debian-devel/2005/01/msg00417.html(...)

Suivre le flux des commentaires

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