Cela utilise donc une feuille XSLT qui transforme un document XML en document XSL-FO, celui-ci contient alors toutes les informations de type pagination, présentation, dénomination. De là vous pouvez produire du pdf, PostScript. ou TeX, rtf qui eux peuvent être imprimés.
Et comme d'habitude, cela peut être appliqué à tous les documents XML, y compris XHTML... si il est bien formé (pas besoin d'être valide)!
(NDM: Attention, l'application d'une feuille XSL de transformation avant l'utilisation de FO peut être nécessaire)
Les changements concernant les tables et les espaces les rendant plus souples
Update du modérateur: quelques petites corrections effectuées...
Aller plus loin
- W3C recommendation (4 clics)
- FOP d'apache fondation (8 clics)
- Un tutorial xml->pdf (15 clics)
- Tutorial XSL (12 clics)
- Des liens sur XSL (8 clics)
# TeX et RTF
Posté par Infernal Quack (site web personnel) . Évalué à 7.
jfor ( http://www.jfor.org(...) ) permet de faire du rtf mais il reste pas mal de boulot et pour le format TeX, j'ai pas trouvé :(
Merci de votre aide
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: TeX et RTF Mode d'emploi du W3C
Posté par Anonyme . Évalué à 10.
Plus génralement, sur le site du W3C ils listent et testent toujours toutes les implémentations de leur standard, donc =>
http://www.w3.org/(...)
puis XSL
du coup t'es sur
http://www.w3.org/Style/XSL/(...)
puis à gauche, dans la case implementation, une liste de liens...
Pour SVG, par exemple
c'aurait été
www.w3.org
puis SVG, puis implementation...
pour...
bon j'arrête là, vous m'avez compris...
[^] # Re: TeX et RTF
Posté par Anonyme . Évalué à 3.
Il y a plusieurs avantages par rapport à XSL:FO:
L'implémentation originale de TeXML est en Java et disponible sur alphaWorks. J'en ait écris une version en Ruby dispo sur ma page web (avec des explications peut-être plus claires): http://purl.org/net/home/pcdavid#texml.rb(...)
[^] # Re: TeX et RTF
Posté par Gaël . Évalué à 1.
Est-ce que ça permet de faire une traduction en HTML aussi avec la bonne feuille de style (j'aime pas latex2html, ça me met chaque paragraphe sur une page différente, c'est lourd) ?
Et si oui, est-ce qu'il existe alors un traducteur latex2texml ?
[^] # Re: TeX et RTF
Posté par Anonyme . Évalué à 0.
% $EDITOR doc.xml
% xslt -style doc2texml.xsl doc.xml > doc.texml
% texml.rb < doc.texml > doc.tex
% latex doc.tex
ou plus simple:
% xslt -style doc2texml.xsl | texml.rb | latex
Comme ton document source est en XML, tu peux facilement le manipuler et en faire ce que tu veux, par exemple du HTML:
% xslt -style doc2html.xsl > doc.html
Il y a plus d'explications sur ma page web (http://pc.david.free.fr/(...)) avec un exemple d'utilisation en bas de la page, et un lien vers l'article qui décrit TeXML en détail.
# enfin ??
Posté par PLuG . Évalué à 10.
c'est a dire, est-ce que en plus de décrire les pages comme le font postscript et pdf, ce format permet de travailler facilement sur le document ?
le fait que ce soit de l'xml me laisse penser que peut-etre que oui ?
si oui, on a peut etre enfin le format standard d'change de document qu'il va falloir pousser pour remplacer le ".doc".
on aura alors le pdf pour s'échanger des doc finies et le xsl-fo pour s'échanger des docs de travail.
j'ai pas le temps de me renseigner mieux, qqun pour confirmer/infirmer ?
[^] # Re: enfin ??
Posté par Jake Justus . Évalué à 10.
En récupérant la DTD des fichiers StarOffice, il ne resterait plus qu'à créer un XSL... A mon avis, faisable, mais beaucoup de boulot.
[^] # Re: enfin ??
Posté par Jean-Pierre Heraton . Évalué à 3.
faut que je pense à creuser cette piste. merci de l'id
[^] # Re: enfin ??
Posté par Rossel Olivier . Évalué à -1.
[^] # Re: enfin ??
Posté par daniel . Évalué à 4.
Il y a déja des fonctions d'import-export pour abiword et c'est le format standard de kword (ou c'est le contraire, je sais plus).
c'est déja utilisé notamment par http://linuxdoc.org.(...)
[^] # Re: enfin ??
Posté par G. R. (site web personnel) . Évalué à 8.
De la même façon que TeX ou LaTeX.
Le format d'échange peut être le document XML lui-même (libre au destinataire d'utiliser ses propres feuilles de styles et processeurs pour l'utiliser) ou le document formatté (HTML, PDF, ASCII, ...).
On peut bien sûr fournir aussi l'ensemble, comme on fournit les sources d'un programme dans un logiciel libre, mais ça n'a pas la même vocation.
[^] # Re: enfin ??
Posté par PLuG . Évalué à 7.
a savoir:
1/ envoyer un document a qqun (le pdf fait cela tres bien)
2/ envoyer un document de travail a qqun. la le pdf ne marche pas, c'est difficile a modifier, du coup le .doc est de mise des que l'on veut être sur que le destinataire pourra en faire quelque chose (et encore ...).
j'espérai que ce standard soit aux documents ce que l'opensource est aux logiciels. Que l'on puisse enfin décider de livrer un document binaire/compilé (pdf) ou source/modifiable ( xsl-fo ?)
bon apparement d'après les premières réponses, ce format serait un peu l'équivalent du .o dans une compilation, reste plus qu'a linker vers le binaire adéquat, mais on ne dispose pas vraiment du source ... domage.
les applis qui sauront produire du xsl-fo seront donc garanties que derriere des traducteurs adequat permettront d'imprimer, de pdfiser ... c'est déjà ca (mais est-ce que cela apporte beaucoup par rapport au pdf ?).
[^] # Re: enfin ??
Posté par Jake Justus . Évalué à 2.
[^] # Re: enfin ??
Posté par boubou (site web personnel) . Évalué à 8.
Pour faire la transformation, on utilise un moteur XSLT (par exemple xalan, cf http://xml.apache.org/(...) ). Pour interpréter le résultat, on utilise un formatteur (par exemple FOP, http://xml.apache.org/fop/index.html(...) ) qui transforme le fichier FO en un autre format (par exemple du pdf). Il n'y a donc pas de transformation FO.
On peut bien entendu utiliser XSLT seul, par exemple pour transformer du XML quelconque en un autre XML quelconque, ou encore en du HTML.
On peut aussi utiliser FO seul, à condition de savoir écrire directement en FO (après tout, c'est du XML, donc c'est faisable).
La recommandation XSL contient à la fois la partie sur XSLT et celle sur FO.
[^] # Re: enfin ??
Posté par Sébastien Koechlin . Évalué à 3.
Pas nécéssairement, XSL-FO est un format de fichiers. On n'est absolument pas obligé de partir d'un autre document XML et d'appliquer une feuille de style pour l'obtenir. Il est possible de générer directement un document XSL-FO valide sans passer par des documents intermédiaires, même si ce n'est pas courant.
un second traitement qui permet de transfomer le fichier de transition en un format *évolué*
On peut envisager XSL-FO comme un format final, qui sera directement utilisé sans transformation ultérieur par un interpréteur. Peut-être que les prochaines version des navigateurs supporteront cela.
[^] # Re: enfin ??
Posté par G. R. (site web personnel) . Évalué à 9.
Prenons l'exemple de ma boite :
L'échange de documents en cours (documentation technique) de rédaction ce fait via XML. Le gros avantage c'est que les destinataires se concentrent sur le fond et non sur la forme.
Ensuite la production du document final est effectuée via des processeurs (Perl avec XML::Parser et DOM) et des feuilles de styles standards (pour le groupe).
Le document final est diffusé en plusieurs formats selon le destinataire (PDF, Slides, HTML)
C'est je crois un bon mode de fonctionnement.
Il y a un format de travail (XML) que tout les intervenants peuvent comprendre et modifier, et un format d'échange pour la version finalisée, qui empêche justement les modifications (enfin en partie).
XSL-FO permet la même chose en plus simple peut-être.
Le principe même de Word est une hérésie (je sais j'exagère un peu, mais c'est pour mieux me faire comprendre). C'est très peu pratique pour faire des documents bien faits et pour les échanges de travail (problèmes de versions des logiciels notamment) et c'est totalement inadapté pour des documents finaux qui ne doivent pas être modifiable et doivent être pérenne (lisible même dix ans après indépendamment de la source).
[^] # Re: enfin ??
Posté par drakmaniso . Évalué à 1.
En d'autres termes, avez-vous une approche "à la SGML", ou plus libre? Et à quoi ressemblent les balises utilisées? Sont-elles basées sur (X)HTML, ou inventées de toute pièces?
En tout cas, c'est sûr que c'est un exemple à suivre... Si seulement le milieu de la recherche pouvait arriver à se mettre d'accord sur un tel type d'échange XML... ("Pour soumettre un short paper, nous acceptons les documents XHTML avec les modules Foo et Bar, plus le module Xyz pour tous les autres types d'articles"). Sans parler de l'éducation nationale ("carnet-de-note.dtd"), de l'administration ("feuille-d-impot.dtd")... Mais là, c'est de la science-fiction! :(
[^] # Re: enfin ??
Posté par boubou (site web personnel) . Évalué à 6.
Un des avantages par rapport à pdf, c'est qu'on peut traduire vers du tex et du rtf, donc de récupérer un document existant comme base de travail pour un nouveau document. Autre avantage, tu peux produire relativement facilement du XSL:FO à partir de XML, donc en gros à partir de n'importe quoi. Je ne sais pas produire du pdf autrement qu'à partir de postscript ou du tex, ce qui complique quand même les opérations (oui, je sais on peut utiliser distiller, mais ce n'est pas gratuit et encore moins opensource).
L'opensource des documents, si ça a un sens, c'est plutôt XML. Et justement, l'apport de XSL:FO, c'est de fournir enfin une impression de qualité, alors que pour l'instant, il n'y avait pas grand chose pour imprimer proprement du XML. Notons tout même que (La)TeX est aussi l'opensource du document, et depuis très longtemps.
[^] # Re: enfin ??
Posté par Philippe Martin . Évalué à 4.
Le fichier XSL, lui, est juste un "style" qui permet de créer le fichier de publication à partir du fichier de travail (et de vérifier en cours de travail que tu ne fais pas n'importe quoi - l'équivalent du WYSIWYG). Mais ce fichier XSL n'a rien d'absolu. Celui qui connaît bien DocBook par exemple n'a besoin d'aucun XSL ou autre "style" pour "voir" un document correctement.
L'embêtant c'est qu'avec un fichier XML seul sans XSL, ma secrétaire ne comprends plus rien. Ce qu'il suffit, à mon avis, est que soit ma secrétaire ait son XSL perso, soit qu'il existe des XSL standards, utilisés par défaut, si tu n'as pas ton XSL perso.
[^] # Re: enfin ??
Posté par boubou (site web personnel) . Évalué à 9.
XSL:FO est le langage de présentation de XSL qui est l'activité "styles" du W3C. Contrairement à ce qu'indique la news, il ne s'agit pas d'un langage à la postscript, car il n'y a pas de possibilité de programmation (pour ceux qui débarquent, postscript est un vrai langage, on peut faire des calculs, etc.). XSL:FO n'est pas non plus un langage à la TeX pour les mêmes raisons. C'est vraiment un langage de description de pages de bas niveau, un truc qui donne les fontes, les marges, les retraits et espacements, etc. En un mot, c'est inutilisable à la main.
La bonne façon de faire, c'est de transformer un fichier XML bien propre (c'est-à-dire adapté au métier) en un fichier XSL:FO, grâce à une feuille de style XSLT (la partie transformation de l'activité "styles" du W3C). C'est d'ailleurs ce qu'explique la news dans un français délirant.
L'avantage de cette solution est d'avoir un fichier XML de départ qui obéit à sa logique propre, et de pouvoir produire des fichiers dans différents format HTML, XHTML, XSL:FO, etc. adaptés à la visualisation qu'on veut obtenir.
[^] # Re: enfin ??
Posté par Sébastien Koechlin . Évalué à 10.
C'est un peu le HTML 3.2 pour le papier. Et encore, HTML permet de baliser des emails, des citations, des exemples... choses qui n'existent pas en XSL-FO. Il existe des notions de styles, similaire dans le vocabulaire aux CSS, mais je n'ai pas trouvé de feuille de style permettant de déclarer des classes.
Le format ne se prête pas vraiment à des modifications ultérieur à cause de l'emboitement qui casse un peu la structure du texte, il est a mon avis non trivial à éditer, quoi que plus facile que le PDF ou le PS.
Par contre, pour la génération automatique de documents (factures en PDF par exemple), c'est génial !
[^] # Pas encore... (Re: enfin ??)
Posté par drakmaniso . Évalué à 2.
Amha, ce n'est pas possible car les formats des documents Word, KWord, AbiWord etc. ne contiennet pas que de la mise en page, mais aussi des informations plus sémantiques (architecture du document), tel que les styles (i.e. désigner ce qui est un titre, une note de bas de page ou de fin de section, une référence biblio...). Or, à ma connaissance, XSL-FO ne cherche à décrire que la mise en page. Il serait bien sûr possible d'ajouter des éléments et attributs pour remplir ce rôle, mais il fauddrait le faire de façon standard, et là on se retrouve à la case départ...
C'est exactement le même problème qu'avec SVG: la plupart des outils de dessins vectoriels récents ont un format natif basé sur SVG, mais avec des extensions non standards, afin de pouvoir sauvegarder des informations plus abstraites.
En fait, je pense qu'un meilleur candidat comme format d'échange serait XHTML, notamment depuis sa modularisation qui a permis de retrouver la "pureté" d'intention du tout début d'HTML (i.e. balisage de l'architecture du document, pas de sa mise en page). Avec en plus les attributs "class" et "id", les éléments "span" et "div", et un sous-ensemble de CSS, il serait sans doute possible de coder dans un seul fichier toutes les infos actuellement enregistrées dans un ".doc".
De plus, il ne suffit pas d'avoir des standards propres et officiels (ils sont déjà là): ce dont nous avons besoin, c'est d'outils bien faits et répandus utilisant ces standards. Il faut aussi que les gens voient un intéret immédiat à leur utilisation: HTML a fonctionné parce qu'il apportait quelquechose qu'aucun autre format n'avait. Si l'on veut qu'un nouveau format de document s'impose, il ne faut pas seulement qu'il puisse faire tout ce que font les autres, il faut qu'il fasse plus! Et la portabilité, dans le contexte actuel, n'est pas une nouveauté suffisante (la plupart des gens qui ont besoin de portabilité se satisfont tant bien que mal de RTF).
Un truc qui pourrait peut-être fonctionner, ce serait un format suffisament souple pour traduire sans perte d'information les formats les plus répandus. Si les gens peuvent convertir tous leurs ".doc", ".pdf", ".tex", ".html" vers un format unique, en étant absolument sûr de ne rien perdre...
On peut toujours rêver!
# ça cause bien la france par ici
Posté par pas_moi . Évalué à 5.
[^] # Re: ça cause bien la france par ici
Posté par Anonyme . Évalué à -2.
Y'a bien des modérateurs, pourquoi pas des correcteurs ?!
Moi, je votes pour à donf'
Vive la bonne langue !!
Faut bien la manier!!
[^] # Re: ça cause bien la france par ici
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 7.
C'est trollhunter qu'il faut engueuler, pas tous les modérateurs hein ;-)
Enfin si quelqu'un a une idée comment corriger cette phrase qui n'a pas de sens, parce que moi je vois pas.
[^] # Re: ça cause bien la france par ici
Posté par GP Le (site web personnel) . Évalué à 2.
Cela utilise une feuille de style XSLT qui transforme un fichier au format XML dans le format XSL-FO. Ce dernier contient alors toutes les information concernant la pagination, la présentation et la dénomination.
par contre l'orthographe...
[^] # Re: ça cause bien la france par ici MEA CULPA de l'auteur mortifié et honteux
Posté par Anonyme . Évalué à 0.
je suis dans le couloir par lequel tout le monde arrive au boulot, l'écran face à l'entrée.
je la news W3C dans mes mails, et je me dis tiens, une news pour linuxfr.
Je savais pas ce qui m'attendais : L'enfer, la guerre et la honte publique.
Je commence à taper la news sur mon navigateur, puis je poste. une fois, deux fois, trois fois.
Puis Et m...
Opéra, ca marche pas..
Je sors mon mozilla de derrière les fagots,
Copier, coller de l'url, du titre, du texte...
Aie... les sauts de lignes sont multipliés par dix !! alors souris, suppr, souris, suppr...
Et m...
Mozilla décide au pif si c'est curseur souris ou curseur clavier... du coup, des suppr aléatoires... dans mon texte...
puis submit... 2/4... puis submit 2/4 encore, je resubmitte... et là pas le temps de relire déjà 4/4 !!!
Et tout ca en maitrisant l'art du 'panic windows shading' toutes les 3 secondes... à chaque fois que qq arrivait dans la boite...
POSTER, C'EST l'ENFER !!!!
Bref, des 'correcteurs savants', aux droits de modifs sur texte pour orthographe, c'est pas une mauvaise idée... c'est pas toujours facile de s'occuper de l'orthographe... Des gens doués, pourraient de plus nous en apprendre...
Et la phrase originale :
' Cela s'utilise uniquement par le biais d'un stylesheet XSLT qui transforme un fichier XML en fichier XSL-FO, qui contient alors toutes les information de type pagination, présentation, dénomination. '
Tk, qui profite de la pause café, ou plus personne ne passe par le couloir...maintenant je ne posterais plus qu'entre 11h et 11h30 ! Trop dangeureux sinon !!
[^] # Re: ça cause bien la france par ici MEA CULPA de l'auteur mortifié et honteux
Posté par Anonyme . Évalué à 0.
[^] # v'là
Posté par Val (site web personnel) . Évalué à 2.
[^] # Une interface de correction communautaire ?
Posté par Wawet76 (site web personnel) . Évalué à 5.
Il pourrait y avoir sur la page d'une news (ou mieux dans un popup pour ne pas surcharger les pages) un petit champs texte style tribune pour poster les remarques d'ordre orthographique ou grammatical.
Ce qui est posté ne serait visible que par ceux qui ont la possibilité de modifier les news pour éviter le moulage tribunesque.
Avec un petit bouton pour effacer toutes les remarques entrées après avoir fait les modifs, ça serait le top.
[^] # Re: ça cause bien la france par ici
Posté par Anonyme . Évalué à -1.
Personnellement je prefere lire un commentaire truffe de fautes mais au contenu interessant, qu'un message correcte mais imbecile comme le tien.
[^] # Re: ça cause bien la france par ici
Posté par Anonyme . Évalué à -4.
correct, sans "e"
et puis tu sais pas mettre d'accents dans tes posts ?
[^] # Re: ça cause bien la france par ici
Posté par Anonyme . Évalué à -3.
D'une part je possede un clavier qwerty, ensuite je fais ce que je veux.
Je suis alle plusieurs fois dans l'Himalaya et pourtant ta connerie me donne le vertige.
[^] # Re: ça cause bien la france par ici
Posté par pas_moi . Évalué à 5.
/sbin/trolld: segmentation fault (core dump)
Qu'il y ait des fautes de français dans les commentaires a très peu d'importance (personnellement, je m'en balance), mais des news avec de telles fautes, ça ne devrait pas arriver.
tout depend du degre
Le degré, c'est que linuxfr est l'un des principaux sites francophones au niveau des logiciels libres.
[^] # Re: ça cause bien la france par ici
Posté par oliv . Évalué à 4.
Elles le sont. En tant que modérateur, je n'ai encore JAMAIS vu de news de plus de 3 lignes sans faute d'othographe.
J'en corrige en moyenne 4 par news. J'ai déjà dû corriger des news avec une faute tout les deux mots (sans exagérer, ce cas m'est arrivé une fois, je n'en croyais pas mes yeux).
Alors évidemment, ce que tu vois, c'est la news avec des fautes parmi les 10 corrigées (où il reste parfois une ou deux fautes, c'est possible).
Les modérateurs sont des bénévoles qui perdent une part importante de leur temps à modérer (modérer une news, c'est au minimum 5 minutes de boulot - vérifier les liens, les catégories, la syntaxe, chercher si elle n'est pas déjà passée - souvenez vous de winamp et windowmaker - et vérifier la pertinence et l'actualité de cette news).
Si tu n'es pas content des news (sur la forme ou le fond), il existe une solution simplissime. Propose nous des news à l'orthographe soignée, au style châtié, sur des sujets pertinents, et nous nous ferons un plaisir de les modérer positivement.
Pour voir les news avant et après leur modération, je peux te dire que 80-90% des fautes d'othographe sont corrigées, et 50% des fautes de syntaxe (on essaie de laisser un certain cachet de l'auteur, et récrire des pans complets de texte, c'est vraiment trop).
[^] # Re: ça cause bien la france par ici
Posté par pas_moi . Évalué à 4.
Les modérateurs font leur travail bénévolement et je les en remercie, comme tout le monde ici, mais ça n'empèche qu'un travail mal fait reste un travail mal fait; dans la FAQ de linuxfr, il va falloir rajouter 'règle number one: il est interdit de dire aux modérateurs qu'une news comporte des fautes de français' comme ça les choses seront claires.
Non, je n'ai pas envie de critiquer un site sur lequel mon navigateur passe plus de 50% de son temps. Au contraire, je fais part de mes remarques pour faire avancer les choses. Si on ne veut pas de commentaires 'idiots' (puiqu'il semblerait que mon commentaire est idiot) qui indiquent les fautes de français dans les news, je suis pour que l'on crée un lien spécial sur chaque news de façon à pouvoir signaler les petites fautes non pas techniques (les commentaires servent à ça) mais plutôt d'ordre linguistique (comme proposé un peu plus haut). Tout ce que je veux, c'est que DLFP soit un bon représentant francophone du mouvement libre (m'en fous que les news passent 3 jours après être passée sur /. parce que personne n'a été capable de fournir la news dans un français correct).
# Utilisation
Posté par Jean-Pierre Heraton . Évalué à 6.
Bien implementé ça pourrait remplacer tous ces moches reports ascii que nous font les pgi
[^] # Re: Utilisation
Posté par Jake Justus . Évalué à 10.
[^] # Re: Utilisation
Posté par Philippe F (site web personnel) . Évalué à 3.
D'un cote, tu definis tous les champs que tu auras dans ton document : titre, paragraphes, auteur. En fait, ca revient a faire ta DTD.
Dans une seconde partie, tu definis exactement comment ton texte va etre rendu, eventuellement ou il va etre place dans ta page. KWord pourrait faire ca tres bien.
Ces deux documents definissent ton modele.
3e etape, tu utilises ton modele et tu tapes ton texte. Tu peux simplement definir de quel est le type du texte que tu tapes (facon lyx). Tu ne t'occupes pas de la mise-en-page, tu n'as pas le droit d'y toucher. L'editeur doit quand meme etre wisiwig (ou cqtvcecqta ?) pour etre plus user-friendly. Ce document serait sauve en XML.
Un tel outil permettrait de produire tres simplement des pages html (en ce qui me concerne), des rapports, des documents internes, des notes, des bouquins, des howto, des faq, ...
L'interet de bien separer les fonctions est fondamental. L'ecriture d'un document devient alors tres rapide, comme avec lyx. Lyx est vraiment pas mal mais il lui manque la possibilite de creer facilement des nouveaux modeles. Et il manque quelques convertisseurs aussi.
Ce genre d'outil peut meme etre utilise pour faciliter la visualisation d'un document XML quelconque. Tu n'aurais qu'a definir le style de chacun des elements vite fait, et hop, un beau document.
Aujourd'jui, XSL, XML et les DTD sont la pour fournir le backend. Ce qu'il manque, c'est une DTD standard pour faciliter l'echange universel, et surtout des editeurs XML oriente comme ca. Tous les editeurs XML que j'ai vu pour l'instant se focalisaient sur le XML, c'est a dire qu'ils affichent un arbre XML et ou tu edites tes tags un par un. Pas du tout ce que je veux. Je veux du Wysiwyg. Je veux que ce soit facile a utiliser. Je veux une vrai interface graphique.
Au passage, le reproche no1 que je fais a latex, c'est ca. Pas wysiwyg. Chiant a utiliser. Alors que lyx est un plaisir, mais manque encore de souplesse.
[^] # Re: Utilisation
Posté par Anonyme . Évalué à 0.
[^] # Re: Utilisation
Posté par - - . Évalué à 2.
Kword ou autre devrait s'orienter vers ca, voir un nouvel outil
il commence à y avoir des editeurs opensource de xml ,pour le moment ca se concentre effectivement que sur l edition de l arbre xml, mais a terme ca s'orientera vers l edition wysywig
en fait, a terme devrait apparaitre une sorte de
mix de lyx/latex/framemaker/editeur html/xml/ bardé d assistants a la word
un veritable environnement de gestion/creation/visualisation de documents modernes
lui indiquant (ou choisissant parmi une palette fournies avec le soft) le dtd / feuille xslt , un tel programme pourrait permettre de creer une foule de type de documents , aussi bien a destination d'un ecran, du web ou à imprimer ,
que les infos soient tapé a la main par l utilisateur ou extraite depuis une base de données (en xml), peu importerait
cela genererait/traduirait aux choix (selon la feuille xslt) vers pdf, du xhtml, rtf etc..
selon le DTD on travaillerait a faire un document dockbook, mathml, etc...
permettrait de faire des howto, des livres, des plaquettes publicitaires, des sites web .
Bien sur l interface devraient permettre de choisir si on extrait les données (l arbre xml en fait) depuis un fichier existant , ou tapé au clavier ou rentrée via un assistant ou extrait depuis une base deonnée
le "type" de document, ca serait le DTD (l utilisateur choisirait dans une liste, l expert pourra donner son propre DTD)
si DTD indiqué, l utilisateur sera forcé a generer un xml valide (l interface proposera les tags, le forcera a ne rentrer que des tags valides selon le contexte etc...)
la forme visuelle du document sera conditionné par un "style" (les feuilles xslt (un peu comme on choisit un "themes" ) ou créé/modifié via des assistants /barres d outils/editeur texte
(genre un bouton gras, un bouton italique appliqué sur les "tags" ) le tout avec interface a la souris, palette etc...
et zou on sauve (en xhtml, en pdf en doc etc... du moment que le soft a les xslt qu'il faut , l expert pourra en rajouter au soft, l utilisateur moyen travaillera avec ceux qui sont fournis par l application/distribution ou son entreprise )
enfin bon, je sais pas si je suis clair.
xml.apache.org a une floppée d outils qui pourrait servir de base, libxml, libxslt et divers trucs de gnome donnent les bases pour manipuler tout ca et divers d autres projets et outils commerciaux
mais il faudrait un enorme effort pour pondre une veritable application GRAPHIQUE FACILE et LIBRE et souple.
je vois assez bien le genre d interface graphique vers quoi s orienter (grosso modo c wysywig avec des palettes pour travailler _au choix_ sur l arbre xml, des assistants, des palettes d outils le tout s adaptant ,orientant l utilisateur selon le DTD xml )
mais la somme de connaissance pour ne serait ce que commencer a programmer ca m ecrase rien qu à y penser
# A quoi ça sert ?
Posté par Yves BAILLY . Évalué à 1.
Mais n'est-ce pas justement la fonction essentielle de LaTeX, de produire des documents papiers de grande qualité, et indépendamment de la plate-forme ? Un PDF généré à partir de LaTeX sous Linux, et un autre sous Windows, sont rigoureusement identiques, je l'ai encore vérifié récemment.
[^] # Re: A quoi ça sert ?
Posté par Philippe Roy . Évalué à 1.
# XSL ou XSL-FO ?
Posté par bobert . Évalué à 1.
XML + XSL -> HTML -> PDF
qui permet d'obtenir à la fois du HTML et du PDF, ou bien la chaine
XML + XSL-FO -> PDF
J'ai cru comprendre que la génération de HTML, puis de PDF via XML+XSL était un moyen plus mature que via XSL-FO, car les outils comme Apache FOP étaient encore largement buggés et pas assez complets ???
J'ai lu ca sur la mailing list docbook-apps, désolé, je retrouve plus la source, mais la conversation était générale et ne portait pas seulement sur des documents XML utilisant la DTD docbook...
De plus, la 2è chaine de traitement ne donne que du pdf, ou bien y'a possibilité de générer du html via xsl-fo ???
Quoi que vous en pensez ??
eul'Bob
[^] # Re: XSL ou XSL-FO ?
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Pour des raisons de présentation :
- passage à la ligne non supporté en HTML
- gestion précise des marges
- ...
De plus pdf2html existe si je ne me trompe pas
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: XSL ou XSL-FO ?
Posté par boubou (site web personnel) . Évalué à 1.
XML + XSLT -> XSL:FO -> pdf, rtf, tex, etc.
XML + XSLT -> HTML -> pdf
La première partie de la chaîne est parfaitement mure au niveau des outils de transformation (xalan, http://xml.apache.org(...) par exemple, fonctionne très bien). Par contre, je trouve que XSL:FO est beaucoup plus lourd à manipuler que HTML (c'est normal, c'est beaucoup plus puissant en terme des rendus possibles).
Pour la deuxième partie (i.e., XSL:FO vers autre chose), il est clair qu'aucun outil open source n'est complet aujourd'hui, ce qui signifie qu'il faut comprendre FO pour savoir si l'outil peut remplir tes besoins (en supposant qu'il n'est pas trop buggué).
En théorie, comme XSL:FO est un dialecte XML, il est tout à fait possible de passer d'un document FO à un document HTML (grâce à une transformation XSLT). Mais c'est profondément idiot, car FO est destiné à la présentation, donc la structure logique du document XML d'origine est complètement détruite. Il est beaucoup plus facile de passer directement de XML à HTML par une transformation XSLT.
Si je résume, je pense qu'il est raisonnable d'investir dans la transformation XML vers HTML qui sera toujours utile. Si tu as un outil HTML vers pdf, tu peux toujours vivre avec en attendant la maturité des outils de formattage (i.e., FO vers pdf, rtf, etc.). Tu peux aussi essayer de comprendre ce que tu peux faire avec FO et voir si les outils de formattage (FOP par exemple) implantent effectivement ce dont tu as besoin. De toute manière, apprendre à écrire une transformation XSLT vers HTML te sera toujours utile comme base pour la transformation vers FO.
# documents XML vs documents .doc
Posté par bobert . Évalué à 2.
<para mode="narquois">D'ailleurs, vu l'usine à gaz, si c'était possible, MS l'aurait déja proposé (ne me parlez pas du mode "suivi des modifications, c'est imbit^H^H^H^Hingérable)</para>
En ce qui concerne des documents XML, on pourrait naivement se dire qu'on prend un serveur CVS et c'est dans la poche. Hum, pas tout à fait. Il manque un système de "diffing" (détermination des différences entre deux documents) XML pour que tout soit OK. Le diffing en XML pose des problèmes plutôt pas simples, si y'a des développeurs que ca tente, lancez-vous, ca rendra service à tout le monde ;-) Voyez l'article http://www-106.ibm.com/developerworks/xml/library/x-diff/?dwzone=xm(...) pour une entrevue des problèmes de "diffing xml", et http://www.logilab.org/xmldiff/(...) pour un outil qui tente de répondre à ce besoin.
A+
eul'Bob
# Quelques bonnes docs...
Posté par tgl . Évalué à 1.
Jettez donc un oeil sur les cahiers 34 à 36, et sur l'article de Chris Rowley dans le cahier 40.
Et puis lisez tout, parceque c'est bien les cahiers de Gutenberg.
T.
# Tips pour docbook
Posté par Gloo . Évalué à 1.
La gestion via SGML est bien plus avancée que la gestion via XML qui n'est ni mur, ni stabilisée ( cette news en est la preuve ). Les specs ne l'etant pas, les outils encore moins.
Si vous avez du mal, quelques tips:
- saxon gère mieux les XSLT que xalan.
- les DSSLs marchent mieux que les XLSs.
En pratique, comme XML est un sous ensemble de SGML, faites vos documents en XML, mettez une declaration SGML et utilisez les outils type jade, jw ( surcouche de jade )...
A court terme, vous vous prendrez moins la tete avec les xslt qui marchent plus ou moins bien. ( plutot moins actuellement )
A "long" terme, le passage vers xml, s'il devait se faire, sera ainsi beaucoup moins douloureux.
Si vous voulez verifier mes dire rien de plus simple:
- faite un document docbook
- faite les transfos via saxon.
- via xalan.
- via jade ou jw
- regardez le resultat, et en combien de temps les transfos sont faites.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.