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
- OOo2DBK sur le site d'Indesko (103 clics)
- OASIS Open (45 clics)
# Bonne nouvelle... et l'inverse?
Posté par Swirly . Évalué à 5.
PS : Bonne année à tous!
[^] # Re: Bonne nouvelle... et l'inverse?
Posté par NOULARD Eric (site web personnel) . Évalué à 3.
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 spell (site web personnel) . Évalué à 2.
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 Eric Cousin . Évalué à 3.
+) 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 ufoot (site web personnel) . Évalué à 3.
http://apps.gotdotnet.com/xmltools/xmldiff/(...)
http://www.logilab.org/projects/xmldiff/(...)
http://diffxml.sourceforge.net/(...)
Le 1er est limité à 100ko ou 200ko par fichier, pas trop saisi mais bon c'est limité, classique vu le fournisseur du soft. Ca marche mais bon je suis pas sûr que ça soit assez souple et libre concernant mes exigences en matière de logiciel 8-) Enfin c'est une excellente "proof of concept", visuelle.
Le 2nd, ben ça produit des jolis fichiers, mais je ne sais pas les exploiter
Le 3ème, ben j'ai eu la flemme de le tester, mais l'a l'air pas mal du tout.
Reste que la puissance de ce type d'outil (diff, patch) est souvent leur fort taux d'intégration dans d'autres outils. En d'autres termes diff et patch c'est pratique parce que CVS le gère, etc. Quid de ces outils XML? Faudrait voir à l'usage...
[^] # Re: Bonne nouvelle... et l'inverse?
Posté par beny (site web personnel) . Évalué à 2.
Le 2nd, ben ça produit des jolis fichiers, mais je ne sais pas les exploiter
Ca produit du XUpdate http://xmldb-org.sourceforge.net/xupdate/(...) mais il n'existe pas AMHA de 'xmlpatch' ...
[^] # Re: Bonne nouvelle... et l'inverse?
Posté par NOULARD Eric (site web personnel) . Évalué à 1.
[^] # Re: Bonne nouvelle... et l'inverse?
Posté par Marc Perron (site web personnel) . Évalué à 3.
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 Philippe F (site web personnel) . Évalué à 7.
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 Vincent Lefèvre (site web personnel) . Évalué à 2.
[^] # docbook aussi dans msword ...
Posté par rzr (site web personnel) . Évalué à 2.
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 norbs . Évalué à 3.
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 governator . Évalué à 6.
[^] # Re: OOo2.0 ?
Posté par adn . Évalué à 1.
- Process the XML generated from the OpenOffice.org 2.x series.
Un peu de patience, donc ;-)
# Quels éditeurs pour DocBook ?
Posté par flyer . Évalué à 0.
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 spell (site web personnel) . Évalué à -2.
[^] # Re: Quels éditeurs pour DocBook ?
Posté par flyer . Évalué à 3.
[^] # Re: Quels éditeurs pour DocBook ?
Posté par SoWhat . Évalué à 6.
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 TImaniac (site web personnel) . Évalué à 3.
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 TazForEver . Évalué à 4.
[^] # Re: Quels éditeurs pour DocBook ?
Posté par TazForEver . Évalué à -2.
SALETÉ DE FREEWARE POUR OUAINDOZE :o
[^] # Re: Quels éditeurs pour DocBook ?
Posté par flyer . Évalué à 1.
Je dois fournir une solution de documentation à des personnes non informaticiennes qui feront des manuels utilisateur.
[^] # Re: Quels éditeurs pour DocBook ?
Posté par Eric Barroca . Évalué à 5.
[^] # Re: Quels éditeurs pour DocBook ?
Posté par flyer . Évalué à 2.
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 lumumba . Évalué à 2.
[^] # Re: Quels éditeurs pour DocBook ?
Posté par Antonio Da Silva (site web personnel) . Évalué à -2.
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 ckyl . Évalué à 0.
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 michauko . Évalué à 0.
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 calandoa . Évalué à 4.
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 NOULARD Eric (site web personnel) . Évalué à 2.
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 Gentoo][Gravis . Évalué à 4.
# Pourquoi pas mais...
Posté par Laurent J (site web personnel, Mastodon) . É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.. (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 SoWhat . Évalué à 3.
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 Frédéric Lopez . Évalué à 4.
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 dinomasque . Évalué à 3.
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 Eric Barroca . Évalué à 2.
[^] # Re: Pourquoi pas mais...
Posté par Frédéric Lopez . Évalué à 3.
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 Antoine Beck . Évalué à 2.
[^] # Re: Gnii ?
Posté par dinomasque . Évalué à 4.
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 Papey . Évalué à 5.
# attaquons les choses sérieuses
Posté par TazForEver . Évalué à -1.
http://www.figuiere.net/hub/blog/?2004/12/20/29-openofficeorg-20-no(...)
[^] # Re: attaquons les choses sérieuses
Posté par Frédéric Lopez . Évalué à 6.
The latest 1.7.2 can be compiled with gcj and accessed from C++ via the CNI interface.
http://www.linuxjournal.com/comment/reply/7800/13123(...)
Requires Java or Kaffe. Kaffe is as third-party to Linux as languages such as Tcl or PhP. In addition, you can even compile HSQLDB with GCJ.
# LaTeX
Posté par Mickaël Sibelle (site web personnel) . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à 8.
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 Mickaël Sibelle (site web personnel) . Évalué à -5.
Merci pour ton explication.
[^] # Re: LaTeX
Posté par Dorianbis . Évalué à 0.
Si si, c'est possible avec la balise emphasis
par exemple,
emphasis role="strong" met les caractères en gras.
[^] # Re: LaTeX
Posté par TImaniac (site web personnel) . Évalué à 4.
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 Yoan B (site web personnel) . Évalué à 4.
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 dinomasque . Évalué à 3.
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 Jack . Évalué à 2.
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 Pierre Jarillon (site web personnel) . Évalué à 3.
Je pense qu'il va falloit transformer tous les documents LaTeX en XML pour en garantir leur pérennité.
[^] # Re: LaTeX
Posté par samds . Évalué à 4.
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 gallenza . Évalué à 3.
[^] # Re: LaTeX
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
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 Matthieu Duchemin (site web personnel) . Évalué à 4.
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 Sylvain Sauvage . Évalué à 9.
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 Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: LaTeX
Posté par Matthieu Duchemin (site web personnel) . Évalué à 3.
[^] # Re: LaTeX
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 1.
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 Sylvain Sauvage . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 3.
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 Barbapapa . Évalué à 5.
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 Pierre Jarillon (site web personnel) . Évalué à 2.
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 Matthieu Duchemin (site web personnel) . Évalué à 2.
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 Sebastien . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
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 Sebastien . Évalué à 2.
Et la logique floue alors ? :P
http://en.wikipedia.org/wiki/Fuzzy_logic(...)
http://fr.wikipedia.org/wiki/Logique_floue(...)
[^] # Re: LaTeX
Posté par Matthieu Duchemin (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 Barbapapa . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: LaTeX
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
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 gallenza . Évalué à 1.
[^] # Re: LaTeX
Posté par jean . Évalué à 1.
é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 samds . Évalué à 4.
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 mdlh . Évalué à 6.
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 ufoot (site web personnel) . Évalué à 3.
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 mdlh . Évalué à 3.
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 Christophe Nowicki (site web personnel) . Évalué à 3.
$ ls **/*.xsl
ooo2sdbk/ooo2sdbk.xsl
$ wc -l ooo2sdbk/ooo2sdbk.xsl
2565 ooo2sdbk/ooo2sdbk.xsl
Le code est assez impressionnant ;0)
[^] # Re: XSLT
Posté par ebellot . Évalué à 4.
- 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 Raphaël SurcouF (site web personnel) . Évalué à 7.
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.