OpenOffice est trop gros et trop lourd pour vous ?
Koffice, vous n'en voulez parque y a un k devant ?
Abiword nécessitant gnome pour l'impression est inacceptable sur votre desktop ?
Pour autant vous aimeriez bien pouvoir lire les documents odf simplement et surtout rapidement sur votre machine.
rassurez vous, vous les accrocs de la ligne de commande (que pour nous c'est plus user friendly que les grosses gui qui puent) et des environnements légers
voici ..... (roulement de tambour)... odfreader !!!!!
c'est un petit programme en perl (4k !!!) donc les seules dépendances sont : xsltproc, unzip et elinks.
Il converti les documents en html et les lit au travers de elinks. Cerise sur le gâteau : il vient avec un odf2html pour se passer de elinks.
D'après mes tests, il est très très rapide, y compris sur les gros documents. Pour le moment il est en version 0.1, et ne fonctionne que sur l'odt mais c'est déjà vraiment bien. Pour les images, elles ne sont pas extraites du zip, mais il suffit d'extraire le dossier Pictures et de le mettre a côté du fichier html.
Très prometteur j'ai hâte de voir la suite.
Le site du projet : http://trac.opendocumentfellowship.org/odf2html/wiki/odfread(...)
Le blog de l'auteur : http://blogs.sun.com/roller/page/dancer?entry=an_accessibile(...)
Et le planet qui va bien (où j'ai trouvé l'info) : http://planet.go-ooo.org/
PS : Testé sous FreeBSD et Linux sans aucun problème
# c'est bient pour mnogosearch
Posté par yopy3700 . Évalué à 5.
# ligne de commande
Posté par mickabouille . Évalué à 1.
Voire même transformer n'imoprte quel type de document en un autre (odf->koffice etc.)
Pourquoi? Pour faire des conversion en batch. Le mieux que j'aie trouvé c'est koffice, qui en gros a une interface ligne de commande. Le problème c'est que pour chaque fichier traité, sur une conversion particulière, il m'affichait une boite de dialogue pour certaines options, et que je n'ai pas trouvé le moyen de fixer ces options. Pas très pratique pour la conversion en masse.
C'est vraiment ce qu'il manque à OOO je trouve (et non, je n'ai pas le temps de me mettre à UNO).
En tout cas, ce projet là c'est deja pas mal pour moi.
[^] # Re: ligne de commande
Posté par Bapt (site web personnel) . Évalué à 4.
Mais surtout ce qui serait intéressant c'est que d'autres feuilles de styles viennent se rajouter au même projet, afin de pouvoir générer du docbook, du fo pour avoir du PDF, ...
dans les projets de http://trac.opendocumentfellowship.org/ , il existe d'autres feuilles de styles, pour les conversion, mais il faut faire les extractions à la main, et donc faire ce que fait odfreader, mais manuellement.
[^] # Re: ligne de commande
Posté par seginus . Évalué à 1.
[^] # Re: ligne de commande
Posté par seginus . Évalué à 0.
http://linuxfr.org/2006/07/01/21046.html
[^] # Re: ligne de commande
Posté par seginus . Évalué à 4.
Merci d'avanche, j'aimerai me coucher moins bête que quand je me suis levé (en fait, pour ça c'est bon, j'ai appris des trucs déjà aujourd'hui).
[^] # Re: ligne de commande
Posté par Larry Cow . Évalué à 7.
Cairo est une librairie graphique 2D vectorielle, inspirée du modèle PDF (mais non calquée dessus), et permettant d'utiliser différents "backends" - ou modules de sortie - pour réaliser son affichage. Ainsi, on peut envisager de "rendre" une image Cairo vers X11, vers OpenGL (via GLX, AGL, WGL, glitz, etc.), DirectFB, Quartz, et j'en passe. On peut aussi envisager de faire sortir le résultat vers un fichier, notamment du PDF.
M'enfin c'est aussi lié à la bureautique que C++ aux jeux vidéos : ça sert pas qu'à ça et c'est pas spécialement fait pour.
[^] # Re: ligne de commande
Posté par seginus . Évalué à 3.
[^] # Re: ligne de commande
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 2.
WeeChat, the extensible chat client
# C'est une bonne nouvelle.
Posté par seginus . Évalué à 6.
Donc c'est bien que cet avantage soit utilisé.
J'espère voir bientôt arriver des viewer légé intégré à nautilus et konqueror et des viewers simple très légé (comme ça, l'odf pourrait remplacer aussi le pdf).
[^] # Re: C'est une bonne nouvelle.
Posté par olgk . Évalué à 2.
Aaah, oui bien sûr. ODF est un format "gentil" et PDF est un format "méchant". Suis-je bête.
[^] # Re: C'est une bonne nouvelle.
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: C'est une bonne nouvelle.
Posté par puzzle . Évalué à 1.
Il suffit d'utiliser pdftk. http://www.accesspdf.com/pdftk/
[^] # Re: C'est une bonne nouvelle.
Posté par EmmanuelP . Évalué à 2.
Oui, enfin, on peut remplacer un caractère par un autre avec vi, pas beaucoup plus.
[^] # Re: C'est une bonne nouvelle.
Posté par Gniarf . Évalué à 5.
[^] # Re: C'est une bonne nouvelle.
Posté par seginus . Évalué à 2.
- Le PDF n'est pas libre. Il est juste bien documenté mais rien n'empèche un jour à acrobat de faire comme pour le jpeg (des partenariats et rachats arrivent si vite)
- Le PDF est lourd par rapport à de l'ODF (enfin je trouve)
- Le PDF n'est pas fait pour être éditable (même si c'est possible d'arriver à éditer du pdf, si personne n'utilise le PDF comme échange de fichier modifiable il y a peut-être une raison.
- Le PDF est je pense nettement moins simple à implémenter que l'ODF (je doute que l'auteur du programme cité dans ce journal aurait pu le faire aussi facilement qu'avec du pdf)
- Enfin, Pourquoi faire des fichiers PDF pour la simple diffusion alors que la source du document pourrait être lisible aussi simplement ?
Voilà les raisons pour lesquelles je pense souhaitable que le l'ODF prenne la place du PDF.
[^] # Re: C'est une bonne nouvelle.
Posté par Anonyme . Évalué à 3.
La raison, c'est que le logiciel permettant de le faire doit coûter dans les 100 euros, et que les gens qui ont besoin de s'échanger des fichiers à modifier le font déjà au format .doc !
[^] # Re: C'est une bonne nouvelle.
Posté par seginus . Évalué à 2.
[^] # Re: C'est une bonne nouvelle.
Posté par Éric (site web personnel) . Évalué à 8.
Tu peux m'expliquer ta définition de format "libre" ?
PDF a des spécifications très précises, publiques, et librement implémentables et en lecture et en écriture. Tu peux faire un logiciel libre qui lit ou/et écrit du PDF.
Les deux formats viennent d'une société (ODF c'est le sxw de Sun un peu modifié). La seule différence c'est que la communauté a un peu collaboré à ODF et que c'est le chouchou du moment, mais il n'est pas plus libre.
> Le PDF est lourd par rapport à de l'ODF
Faut voir, le PDF il y a souvent les polices dedans. Assez souvent les PDF contiennent aussi des données à très haute résolution pour impression, plus que ce que tu fais d'ordinaire sur ton traitement de texte. Ca joue beaucoup.
Sur des contenus équivalents et non ridicules, si tu zip ton PDF, la différence de taille ne doit pas être si significative que ça.
> Le PDF n'est pas fait pour être éditable
Certes, tu noteras tout de même que pour beaucou d'usages certains trouvent ça un avantage. Bref, c'est distinctif mais pas disqualifiant.
> Le PDF est je pense nettement moins simple à implémenter que l'ODF
Ca ça reste à voir. Il y a tout de même pas mal de choses dans ODF. PDF il y a plein de libs qui existent déjà partout qui font très bien du PDF (du simple comme du complexe). Pour ODF on ne peut pas en dire autant.
PDF c'est non seulement implémentable mais implémenté.
> je pense souhaitable que le l'ODF prenne la place du PDF
C'est surtout pas les mêmes utilisations. Le PDF ne bouge pas, sera exactement pareil partout. ODF n'embarque même pas les polices, ça limite les exactitudes de rendu.
[^] # Re: C'est une bonne nouvelle.
Posté par Larry Cow . Évalué à 3.
En revanche, dès qu'on veut toucher au fond plus qu'à la forme, ODF (enfin surtout un document ODF bien structuré, avec des styles intelligements choisis et nommés), c'est que du bonheur. Générer des courriers types depuis un modèle ODF, c'est très simple à faire depuis n'importe quel langage de programmation qui propose des fonctionnalités ZIP et XML (Python, Perl, Java, Ruby, etc.), fut-ce via des librairies externes. De même, récupérer le texte d'un ODF est faisable sans librairie spécifique au format.
Bref, comme tu le dis si bien, c'est deux formats qui sont plutôt complémentaires que concurrents, et heureusement. Sinon l'ODF n'aurait aucune chance de percer, vu la position de l'autre.
[^] # Re: C'est une bonne nouvelle.
Posté par olgk . Évalué à 7.
Le PDF est documenté, sa spécification est disponible en ligne et dans les bonnes librairies, l'a toujours été (et est au passage foncièrement plus "libre" que Postscript, cf. DPS). Les quelques patents d'Adobe sur PDF sont automatiquement licensiés par Adobe sur une base royalty-free, nonexclusive pour tout ce qui bouffe et produit du PDF, que ça soit opensource ou non. Un peu comme -surprise, surprise - ce que à fait Sun pour OpenDocument.
D'autre part, différentes variantes de PDF ont été standardisées par l'ISO.
Et au passage, de par ma lecture des specs d'ODF et de PDF (et de OpenXML) je trouve celle de PDF de bien meilleure qualité (rédaction, précision, non-ambiguité).
> Le PDF est lourd par rapport à de l'ODF (enfin je trouve)
Ah ? Sur quelles bases ? Pour quelles utilisations ?
> Le PDF n'est pas fait pour être éditable (même si c'est possible d'arriver à éditer du pdf, si personne n'utilise le PDF comme échange de fichier modifiable il y a peut-être une raison.
Et peut-être que si le PDF n'est pas fait pour être éditable -au même niveau de description- que l'ODF c'est qu'il y a peut-être une raison ? Que par exemple que ODF et PDF travaillent à des niveaux de description radicalement différent ? Que les usages de l'un (document bureautique) ne recoupent pas franchement ceux de l'autre (représentation précise de document arbitraire, y compris
> Le PDF est je pense nettement moins simple à implémenter que l'ODF (je doute que l'auteur du programme cité dans ce journal aurait pu le faire aussi facilement qu'avec du pdf)
Très discutable. PDF a une structure particulièrement simple (flots/objets), et les générateurs PDF sont assez concis. De par ses contraintes (compacité / orientation lecture / très peu de sémantique), les carottes PDF n'ont effectivement pas grand chose à voir avec les choux ODF pour l'exemple donné.
Il est facile de faire convertisseur pour rendu HTML d'un document traitement texte ODF, plus qu'avec PDF ? Je le crois très volontiers.
Maintenant j'aimerais savoir en quoi la même problématique serait en jeu pour un document PDF très peu textuel genre un diagramme de pièce mécanique.
> Enfin, Pourquoi faire des fichiers PDF pour la simple diffusion alors que la source du document pourrait être lisible aussi simplement ?
Parce que ce n'est pas les mêmes usages ? Parce qu'il serait stupide -techniquement- que Gimp ou Dia utilisent ODF nativement ? Parce qu'il serait stupide de diffuser à toute forces du dessin technique, des facsimilés, des catalogues lourdement graphiques de 3500 pages, et plus généralement des documents fidèles graphiquement issus d'un logiciel n'ayant rien à voir avec de la bureautique via un format comme ODF ?
Conclusion ?
J'ai l'air énervé ? Je le suis. Je suis toujours un peu crispé de voir ces discussions sur les formats de fichiers tourner sempiternellement à du FUD de bas étage où les valeurs techniques sont largement ignorées, les problèmes "légaux" traités avec désinvolture et sans vérification, et le monde vu à toute force comme du noir et blanc.
# ?
Posté par farib . Évalué à 4.
Pas compris.
[^] # Re: ?
Posté par Larry Cow . Évalué à 4.
Cerise sur le gateau : il convertit simplement le document et te laisse libre de l'afficher avec l'outil de ton choix.
Ou alors j'ai rien compris non plus.
[^] # Re: ?
Posté par Gmooron . Évalué à 1.
hum
====>[ ]
[^] # Re: ?
Posté par Larry Cow . Évalué à 4.
# emacs / vim
Posté par JoeltheLion (site web personnel) . Évalué à 3.
C'est sur, c'est des éditeurs de texte donc pas d'images etc. (quoi que sous emacs... mais est-ce vraiment souhaitable?)
Bref un truc qui permettrait d'extraire le texte raisonablement formaté d'un odf sous vim, et d'enregistrer un doc vim en odf serait un must, au moins pour moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.