Les autres suites bureautiques libres n'ont quant à elles pas attendu cette nouvelle pour intégrer le format OpenDocument puisque la pré-version 1.4 de KOffice utilise OpenDocument par défaut et la version 2.3 de AbiWord propose aussi le support (pour le moment expérimental) de ce format.
En outre, c'est un grand pas en avant pour l'interopérabilité dans le domaine de la bureautique ; jusqu'à présent la suite Microsoft Office et ses formats propriétaires et fermés dominait le marché. Pour le moment, Microsoft, lui-même membre de l'OASIS, n'a toujours pas réagi officiellement sur le sujet.
Enfin, cette standardisation était un pas indispensable pour l'adoption du format OpenDocument par les instances européennes qui, en plus du format OpenDocument, ont décidé d'auditer le format de la suite Microsoft Office 2003 (voir http://formats-ouverts.org/blog/2004/09/27/132-LeuropeVeutDesFormatsOuverts ).
NdM : c'est le format de la suite bureautique Libre OpenOffice.org qui a été pris comme référence à ce travail de normalisation. C'est également le format de Star Office de Sun, mais aussi bientôt un format géré par KOffice, la suite bureautique de KDE. C'est donc une des grandes nouvelles de ces dernières années dans le domaine des formats ouverts car il n'existait pas de norme dans la bureautique.
NdM : Merci à jcs et à tuiu pol pour cette dépêche Ancienne version de la news :
On en parlait depuis longtemps, cette fois c'est fait : ce lundi 23 mai l'organisme de normalisation OASIS (Organisation for the Advancement of Structured Information Standards) a annoncé que ses membres ont approuvé l'Open Document Format for Office Application (Open Document) v1.0 comme standard.
(Traduction libre) « OpenDocument fournit un schéma simple de XML pour le texte, les bilans, les diagrammes, et les documents graphiques. Il se sert des normes existantes, telles que le HTML, SVG, XSL, SMIL, XLink, XForms, MathML, et Dublin Core, dans la mesure du possible. OpenDocument a été conçu comme concept de paquet, lui permettant d'être employé comme format de fichier de défaut pour des applications de bureau sans augmentation de la taille des fichiers ou de la perte d'intégrité de données. »
Extrait de la FAQ :
What is the current state of the specification?
OpenDocument 1.0 is an approved OASIS Standard, a status that signifies the highest level of ratification.
Who owns OpenDocument?
OpenDocument is owned by OASIS, a not-for-profit organization dedicated to the open development of public XML standards. OpenDocument is maintained by an OASIS Technical Committee made up of XML, document management and office application experts.
How much will it cost to use OpenDocument?
OpenDocument is royalty-free. It can be used without charge by anyone.
Who benefits from this work and how?
An open document format for office applications protects content, whether it is an 800-page airplane specification or a legal contract, from being locked into an application- or vendor-specific file format. Additionally, it lets application users participate in the benefits of XML file formats without having to change their habits and without requiring additional knowledge or education.
Attention toutefois :
au début de l'année, l'OASIS était sur le point d'accepter les brevets logiciels dans leurs standards (un peu comme le W3C à l'époque). AFUL, APRIL, FSF France et OpenOffice.org d'un côté et Groklaw de l'autre avaient alors réagi.
Aller plus loin
- L'annonce sur le site d'OASIS (8 clics)
- DLFP : Le futur est au format OpenDocument (selon l'UE) (8 clics)
- DLFP : Journal : Gnome et OpenDocument (4 clics)
- DLFP : Sun pousse pour que le format des documents OOo devienne une norme (4 clics)
- formats-ouverts.org : Le format de la suite bureautique OpenOffice.org devient un standard de l'OASI (6 clics)
- Le comité OpenDocument de l'OASIS (2 clics)
# Adoption
Posté par arnaudus . Évalué à 9.
OpenDocument risque donc d'être LE format bureatique du libre, mais rien que du libre, et c'est bien dommage.
Il va falloir attendre quelques mois pour voir foisonner les petits scripts de conversion, latex2opendoc, html2opendoc, opendoc2rtf, etc etc. De leur efficacité dépendra l'adoption du format par les utilisateurs...
[^] # Re: Adoption
Posté par Vincent P (site web personnel) . Évalué à 10.
Dès lors, les suites bureautiques propriétaires devront le supporter, sous peine de voir leurs clients passer à des suites bureautiques alternatives qui gèrent ce format.
[^] # Re: Adoption
Posté par neil . Évalué à 3.
[^] # Re: Adoption
Posté par Gof (site web personnel) . Évalué à 3.
[^] # Re: Adoption
Posté par Michaël Larouche . Évalué à 1.
Au moins KOffice lui son interface est plus léger que OpenOffice.org et intégré au reste de KDE :)
Vivement la version finale de la branche 1.4 pour le support OpenDoc.
[^] # Re: Adoption
Posté par M . Évalué à 2.
[^] # Re: Adoption
Posté par Erwan . Évalué à 3.
[^] # Re: Adoption
Posté par Jean Parpaillon (site web personnel) . Évalué à 2.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Adoption
Posté par M . Évalué à 4.
[^] # Re: Adoption
Posté par HallaanLoske . Évalué à 3.
Il y a aussi Visioo-Writter, tres tres jeune.
Les devellopeurs ne demandent que des conseils pour avancer, c'est leurs premier projets.
http://visioo-writer.tuxfamily.org/
@+
HL
[^] # Re: Adoption
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: Adoption
Posté par yves a (site web personnel) . Évalué à 0.
vi ou emacs ?
[^] # Re: Adoption
Posté par darkleon (site web personnel) . Évalué à 1.
>vi ou emacs ?
Clients légers, je commence à avoir des doutes, clients utilisable sous console, c'est déjà plus réaliste.
A l'ére du giga-octect de mémoire tout est relatif
Le poids des archives complétes (sources + docs+ ressources) sous gentoo (j'ai classé par ordre alphabétique pour ne pas faire de Troll :-) :
* app-editors/emacs
Latest version available: 21.4
Size of downloaded files: 23,249 kB
* app-editors/vim
Latest version available: 6.3.068
Size of downloaded files: 4,746 kB
* app-editors/xemacs
Latest version available: 21.4.15-r3
Size of downloaded files: 10,441 kB
Pour comparaison (je triche un peu, les gentooiste trouveront la faille :-)
* app-office/openoffice-bin
Latest version available: 1.1.4-r1
Size of downloaded files: 78,564 kB
* app-editors/nano
Latest version available: 1.3.7
Size of downloaded files: 985 kB
A noter que l'executable de nano fait 116ko sur ma machine.
Quand on se rappelle qu'on faisait du turbo-c ou turbo pascal sous dos avec 640ko avec une ide qui était déjà trés agréable (mais en caractéres).
Que sur mon amiga, j'avais 1mo de ram et que je n'ai jamais autant programmé parce que je considérais qu'il fallait dépasser les limites.
Alors dire qu'emacs ou vim c'est du client léger, rien que la taille de l'archive n'est pas téléchargeable avec un modem 56ko.
Après on aime ou on aime pas, mais plus rien n'est léger en 2005, il faut quand même des procs à >100mhz et >16mo de ram pour faire marcher quelquechose.
Tiens un gars qui fait son serveur web en circuit logique à 3mhz et qui a un meilleur temps de réponse que la plupart des serveurs web "pro", ça c'est même de l'ULM
http://64.142.4.132/(...)
Je ne dis pas qu'avant c'était mieux, je dis que l'informatique est devenue obèse parce qu'on ne cherche plus l'optimisation.
On a la puissance, pourquoi pas, c'est plus zolis, on aplus d'aide contextuelle, c'est pas forcément un mal, et ça améliore même la productivité parfoit
mais arrétons de se leurrer en parlant de "léger"
[^] # Re: Adoption
Posté par ragoutoutou . Évalué à 1.
[^] # Re: Adoption
Posté par Aldoo . Évalué à 5.
Espérons que l'UE ne tombera pas dans le panneau.
[^] # Re: Adoption - "plugin" Msword
Posté par dawar (site web personnel) . Évalué à 7.
[^] # Re: Adoption
Posté par Jllc . Évalué à 2.
Mais du coup, c'est l'occasion de faire rentrer ce format dans une entreprise.
[^] # Re: Adoption
Posté par ragoutoutou . Évalué à 4.
Je bosse dans une banque, et dans ce genre d'endroit, l'ouverture aux nouveautés est directement conditionnée par la compatibilité avec les produits déjà achetés. Pas de révolution possible, les évolutions étant déjà un luxe souvent inacceptable. Si on ne peut ouvrir les documents OASIS avec MS Office, il n'y a malheureusement pas l'ombre d'une chance de les voir adoptés chez nous.
[^] # Re: Adoption
Posté par dawar (site web personnel) . Évalué à 2.
[^] # Re: Adoption
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Très mauvais raisonnement ! C'est justement en envoyant des documents avec des nouveaux formats que l'on oblige son correspondant à se procurer le plugin ou le programme qui permet de les lire.
Ce procédé qui a été employé par Word, Acrobat, Flash, ... Alors, il faut renvoyer l'ascenseur. De cette façon, on peut espérer stopper le rouleau compresseur de Microsoft.
[^] # Re: Adoption
Posté par dawar (site web personnel) . Évalué à 2.
[^] # Re: Adoption
Posté par fmaz fmaz . Évalué à 5.
suffisante. Si je reçois 1 fichier au format .zgk, je remande qu'on
me trouve un autre format. Si j'en reçois 15, je cherche un outil
pour gérer les .zgk (que ce soit un plugin pour truc ou un
programme indépendant).
Supposons que l'état impose le format .zgk pour sa gestion interne
et toutes les communications avec l'extérieur, cela crée une
pression important pour quiconque veut communiquer avec l'état.
À partir de cela, un certain nombre de boites vont trouver un moyen
d'utiliser le format .zgk. Ensuite, ils utiliseront naturellement le
même logiciel ou plugin pour communiquer avec d'autres boites qui,
elles, ne travaillent pas directement avec l'état. De proche en
proche, un certain nombre de boites vont utiliser ce format. On peut
aussi imaginer que les personnes qui se retrouvent à travailler tous
les jours avec des .zgi, vont aussi l'utiliser chez elles. On verra
apparaître des emails: « regarde mes photos de vacances » au
format .zgk et assez vite, tout le monde gèrera le .zgk.
C'est comme tout, il faut une masse critique. L'état peut l'imposer
et comme ils semblent chasser les coûts, il est possible qu'ils
utilisent vraiment openoffice.org et donc les formats associés.
[^] # Re: Adoption
Posté par ragoutoutou . Évalué à 3.
La première migration à faire, c'est celle des institutions publiques. Si eux-même n'utilisent pas des logiciels compatibles OASIS, ça ne sera qu'un mouvement de bureaucratie inutile et coûteux que de réclamer des documents au format OASIS si c'est ensuite pour devoir les reconvertir en word pour usage interne.
Une fois la migration effectuée, là on pourra envisager d'exiger des fichiers au formats OASIS, pas avant.
Mais il y a fort à parier que les entités communiquant avec le gouvernement prendront des convertisseurs et bosseront en interne sous word plutôt que de faire la migration.
En tout cas, sii c'est pour faire une conversion word=>OASIS d'un côté et faire OASIS=>word de l'autre, c'est débile.
Le gouvernement n'a pas vocation à stopper le rouleau compresseur Microsoft.
[^] # Re: Adoption
Posté par fmaz fmaz . Évalué à 9.
boite de Redmond.
[^] # Re: Adoption
Posté par ragoutoutou . Évalué à 1.
[^] # Re: Adoption
Posté par arnaudus . Évalué à 1.
# dépêche
Posté par tuiu pol . Évalué à 8.
[^] # Re: dépêche
Posté par Nÿco (site web personnel) . Évalué à 3.
# Extensions des fichiers : od[tgpsicfmh]
Posté par tzeentch00 . Évalué à 8.
Alors les voilà pour ceux que ça intéresse aussi :
odt pour les documents de texte.
odg pour les documents graphiques (dessin).
odp pour les documents de présentation.
ods pour les documents de tableurs.
odi pour les images.
odc pour les graphes.
odf pour les formules.
odm pour les documents globaux de texte.
odh pour les documents html.
La traduction est approximative et peu-être pas très exacte. L'original se trouve dans le PDF http://www.oasis-open.org/committees/download.php/12572/OpenDocumen(...) (p 697-698)
[^] # Re: Extensions des fichiers : à propos du format
Posté par Mark Havel . Évalué à 3.
[^] # Re: Extensions des fichiers : à propos du format
Posté par Duloup . Évalué à 4.
[^] # Re: Extensions des fichiers : à propos du format
Posté par revponpuneq . Évalué à 10.
Mais il faut déjà que la 2.0 sorte pour que la question se pose, parce que pour l'instant, on n'en est qu'au développement... ;-)
eric bachard
--
ericb@openoffice.org
[^] # Re: Extensions des fichiers : à propos du format
Posté par Duloup . Évalué à 2.
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par Frédéric COIFFIER . Évalué à 4.
A quoi cela peut-il bien servir ??
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par Jllc . Évalué à 5.
A quoi cela peut-il bien servir ??
Peut être à mettre tout un document web (page Html + Css + images) dans un seul document odh ?
Mais ce n'est qu'un hypothèse.
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par riba . Évalué à 10.
dot pour les documents de texte (et donc des document dot dot).
dog pour les documents graphiques (en plus c'est marrant, genre:"envoie-moi le dog faut que je le retouche").
dop pour les documents de présentation (et P'tit Dop?).
dos pour les documents de tableurs (le retour du fils de vengeance du DOS?).
doi pour les images.
doc pour les graphes. (oui bon là ça pose problème)
dof pour les formules.
dom pour les documents globaux de texte.
doh pour les documents html (mais où est homer?).
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par djibb (site web personnel) . Évalué à 10.
-j'ai besoin de l'image... tu me fais un doi, stp ?
-tu veux pas un whisky d'abord ?
/mode off/
----------------------------------------------------------------------------------------->[]
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par riba . Évalué à 2.
explication: je prononce doï en fait, comme oï (punk toussa), donc "d-ou-oy". Ça permet de différencier de doa (DocumentOpen Archive? Animation? Association? ...).
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par bmc . Évalué à 9.
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par riba . Évalué à 2.
note pour plus tard: Je sais que c'est con, mais ma proposition rendrait la "terminologie" OpenDocument bien plus "concrète", et acceptable plus facilement par le commun des mortels. Reste à justifier cette inversion d'ordre, qui n'est pas intuitive en anglais (mais logique en francais/espagnol/italien/...). Desfois l'acceptation d'une norme passe par sa logique et sa simplicité (en l'occurrence 3 lettres réduisible à un seul son, et non pas des trucs barbarres du genre "o-d-t"!). Même en anglais ça marche (=un seul son), donc pourquoi pas le proposer à l'"OpenDocument Fondation" (enfin le truc qui normalise quoi)? Quand on voit la note de mon commentaire (10 actuellement), ça veut bien dire quelque chose, nan?
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par ArBaDaCarBa . Évalué à 1.
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par TImaniac (site web personnel) . Évalué à 2.
Enfin de toute façon sous Linux la plupart des navigateurs de fichiers détermine le type d'un fichier à son type mime et non à son extension, et sous Windows l'utilisateur ne voit pas l'extension (par défaut), donc bon, même si les version od* sont moins facile à prononcer, ils ont l'avantage d'être très peu utilisés.
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par gros_rouge . Évalué à 7.
Le problème avec les fichiers .od* ( et .sx* ) c'est que ce sont des archives Zip. Si tu supprimes le suffixe, ton navigateur te propose d'ouvrir le document avec ton gestionnaire d'archives :-/
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par Éric (site web personnel) . Évalué à 2.
Quand au zip avec une autre extension c'est assez courant (.jar et .xpi par exemple) pour qu'un de plus ou moins n'y change pas grand chose.
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par gros_rouge . Évalué à 3.
Effectivement, ma remarque était mal formulée et pouvait prêter à confusion. J'aurais du m'exprimer ainsi :
« Il n'est pas possible de déterminer le format d'un fichier OpenOffice/OpenDocument à l'aide de son type mime. Les fichiers en question sont des archives Zip et la présence d'une extension est donc nécessaire. »
On peut « reposer sur des trucs ouverts et relativement courants/standards » sans pour autant tout mettre dans une archive Zip et devoir bricoler avec les extensions. Le premier exemple qui me vient à l'esprit est le format des paquets Debian ( .deb ) [1] ; une simple archive ar dans laquelle le premier fichier archivé permet d'obtenir un magic number spécifique.
[1] $ man 5 deb ou http://www.annodex.net/cgi-bin/man/man2html?5+deb(...)
[^] # Re: Extensions des fichiers : od[tgpsicfmh]
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
# J'adore OpenOffice.org, mais...
Posté par Anthony F. . Évalué à 10.
Malheureusement, la gallerie de OpenOffice.org 2.0 (m104) ne permet toujours pas d'utiliser les "OpenClipart.org" au format SVG... ce qui est franchement dommage quand on voit le peu d'objets disponibles par défaut.
C'est limite hors sujet... mais y'a les "moinssages" au besoin ;-)
[^] # Re: J'adore OpenOffice.org, mais...
Posté par revponpuneq . Évalué à 4.
Pour ceux qui peuvent, où qui sont intéressés, ça se passe là : <http://www.openoffice.org/issues/show_bug.cgi?id=2497>(...)
eric bachard
--
ericb@openoffice.org
[^] # Re: J'adore OpenOffice.org, mais...
Posté par Anthony F. . Évalué à 2.
Par contre mon anglais m'empêche de comprendre vraiment cette issue : il s'agit d'importer le SVG, ou de seulement "utiliser" le SVG ?!
La nuance d'utilisation (visu) et d'import (édition) est énorme non ? (je ne suis pas programmeur...)
[^] # Re: J'adore OpenOffice.org, mais...
Posté par Erwan . Évalué à 3.
[^] # Re: J'adore OpenOffice.org, mais...
Posté par Anthony F. . Évalué à 2.
[^] # Re: J'adore OpenOffice.org, mais...
Posté par arnaudus . Évalué à 4.
[^] # Re: J'adore OpenOffice.org, mais...
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: J'adore OpenOffice.org, mais...
Posté par arnaudus . Évalué à 7.
[^] # Re: J'adore OpenOffice.org, mais...
Posté par Nÿco (site web personnel) . Évalué à 4.
- SVG-Tiny dans Opera 8, http://www.opera.com/features/svg/index.dml(...)
- SVG dans Deer Park, le futur Firefox 1.1
- KSVG dans Konqueror en tant que plugin
[^] # Re: J'adore OpenOffice.org, mais...
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: J'adore OpenOffice.org, mais...
Posté par Frédéric Péters (site web personnel) . Évalué à 1.
https://bugzilla.mozilla.org/show_bug.cgi?id=18574(...)
# Est-ce suffisant pour une bonne interopérabilité
Posté par sharko . Évalué à 10.
Or, je vois deux failles dans cette approche.
1: Il me semble bien que OpenDocument permet d'utiliser des champs « propriétaires » spécifiques à une application (foreing elements chaptitre 1.5).
Supposons que ce format devienne obligatoire ou imposé pour des réponses à appel d'offre.
Or supposons qu'un éditeur ce veux pas de cette compatibilité (il cherche à verrouiller l'utilisation de son logiciel que ses super marketeux sont arrivé a vendre comme des petits pains).
Mais cette éditeur souhaite quand même obtenir le label « OpenDocument » pour pouvoir le vendre à des société qui l'exige.
Il peut utiliser un format 100% Valide en OpenDocument en utilisant de façon intensive des champs « propriétaires » quitte à utiliser ses champs même pour des propriété triviaux qu'il aurait pu décrire en utilisant des champs de la norme (genre mettre le texte dans un « foreing element » mais codé en rot13). Les autres softs ne pourront pas le lire car ils ne pourront pas interpréter correctement des propriétés indispensables.
De plus, il peut même décrédibiliser openOffice et consort en se permettant de lire leurs fichiers alors qu'eux ne peuvent pas (</mauvaise fois on>quelle bouse ce oo, il ne peut même pas lire ce fichier openDocument valide alors que mon magicOffice y arrive sans problème <mauvaise fois off>)
2: Je ne vois comment traiter correctement l'écart de fonctionnalité entre les soft (même entre des soft qui « jouent le jeux »)
OpenDocument est un format intégrant le maximum de fonctionnalité. Chaque suite bureautique n'utilise qu'une partie de celle-ci. Mais si la suite A utilise une propriété qui à un impact sur le fichier, rien n'assure que la suite B saura l'interpréter correctement. Et si cette propriété m'est indispensable pour la bonne compréhension du document, j'ai un problème. Prenons par exemple une transition dans une diapositive qui me permet de faire apparaître un élément graphique de manière particulièrement éclairante pour ma présentation. Je créé mon document sous Oo. Je l'envoie à mon client. Il le lit sous KOffice et n'y comprend rien.
Je ne peut donc pas envoyer un document (même si c'est OpenDocument) à une personne en étant sur qu'il puisse tout lire, le modifier et me le renvoyer sans problème.
En conclusion :
Si mes peurs sont justifiées, je vais être déçus. Bien que cela soit une grande avancée dans l'interopérabilité, pour moi, cela ne permet pas d'avoir un document d'échange éditable sans soucis. Et je pense que cela à été sur-vendu et que la déception qui pourrai en suivre serai très dommageable.
__
Je me suis laché pour mon premier post
[^] # Re: Est-ce suffisant pour une bonne interopérabilité
Posté par arnaudus . Évalué à 3.
Les informations spécifiques ne devraient concerner que les fonctionnalités impossibles à implémenter dans OpenDocument. Ainsi, tout passerait "le mieux possible", tout en préservant des informations mineures si on a la chance de l'ouvrir avec la même appli. J'imagine que ces champs "propriétaires" sont là pour permettre de garder un format OpenDocument natif, tout en faisant évoluer les capacités du logiciel.
Si on peut utiliser ces champs pour y mettre des choses qui devraient être ailleurs, alors c'est la porte ouverte à tous les abus, parce que 1) certains ne vont pas se priver d'y mettre tout et n'importe quoi pour se rendre incompatibles avec le reste du marché, et 2) certains vont trouver de bon ton de lire ces champs pour se rendre compatibles avec le premier "tricheur", je ne vous raconte pas le bordel.
En ce qui concerne la perte d'information dans les softs les moins évolués, j'ai des doutes. En effet, le XML est particulièrement bien adapté à ça : un champ qu'on ne connait pas, on ne le lit pas, et il reste tel quel. Donc on enregistre, et l'information persistera. Alors oui, ça ne "passera" pas pareil, mais au moins, il n'y aura pas de perte lors des aller-retours. Enfin ça, c'est dans un monde idéal, quand même...
[^] # Re: Est-ce suffisant pour une bonne interopérabilité
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
oui MAIS supposons que les organismes public qui exige le format OpenDocument n'est pas asser d'argent (les organisme public sont TOUJOURS en manque d'argent)pour acheter la super suitedelamortquituetcompletementferme et utilise plutot le logiciel libreparcequecestgratuit.
alors l'entreprise qui voudra echanger des fichiers avec les organismes public devront se conformer au logiciel libre (et n'acheterons pas magic office)
et l'experience montre que les organisme public se mettent au logiciel libreparcequecestgratuit (munich,mairie du 13eme, gendarmerie, ...)
J'ai plus qu'une balle
[^] # Re: Est-ce suffisant pour une bonne interopérabilité
Posté par Mildred (site web personnel) . Évalué à 2.
Ce serait bien qu'ils contribuent aussi .... que ce ne soit pas simplement par souci d'aconomie.
[^] # Re: Est-ce suffisant pour une bonne interopérabilité
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: Est-ce suffisant pour une bonne interopérabilité
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
# un viewer rapide ?
Posté par Xavier Teyssier (site web personnel) . Évalué à 5.
Il faudrait donc écrire un visualisateur léger qui tourne sous toutes les plate-formes...
Note : le "léger" est là pour éliminer Openoffice et Acrobat Reader !
[^] # Re: un viewer rapide ?
Posté par phoenix (site web personnel) . Évalué à 2.
[^] # Re: un viewer rapide ?
Posté par GCN (site web personnel) . Évalué à 4.
Vas-y fais le :) comme ça, même les utilisateurs de MS-Office sauront comment c'est désagréable de recevoir un fichier dont on ne possède pas le soft pour le lire.
Après si ils sont honnêtes, y'aura pas longtemps à choisir entre un truc qui coûte la peau des *ouilles et un truc pas cher !
[^] # Re: un viewer rapide ?
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: un viewer rapide ?
Posté par rhizome . Évalué à 3.
[^] # Re: un viewer rapide ?
Posté par Etienne Juliot (site web personnel) . Évalué à -1.
Tu remontes de 3 pages, et tu as la réponse à ta question.
Bon allez, je suis gentil je te file le lien du commentaire :
http://linuxfr.org/2005/05/26/19006.html#579448(...)
et même le lien vers le projet de visionneuse opendocument : http://visioo-writer.tuxfamily.org/(...)
[^] # Re: un viewer rapide ?
Posté par manalfer . Évalué à 8.
Il faut le comprendre : tout le monde n'a pas la capacité de visualiser l'avenir et de lire les messages postés plus de deux heures et demi après...
[^] # Re: un viewer rapide ?
Posté par Gart Algar . Évalué à 4.
Tellement plus pratique
# Ceci n'est pas une norme
Posté par Mes Zigues . Évalué à 5.
Une des caractéristiques d'une norme, en droit fanrçais, est d'être opposable dans les appels d'offres. Pour cela, le texte doit être publié, avec un niveau norme, soit par le CEN (comme ça c'est pareil dans tous les payes européens) soit par l'AFNOR (la publication à l'ISO n'impose rien au niveau français).
Pour le moment, rien n'oblige (ni n'interdit) un acheteur public à mettre dans son appel d'offres l'obligation que les logiciels bureautiques achetés produisent des fichiers conformes à Opendocument.
Quelqu'un aurait-il des information sur l'adoption d'Opendocument par les instances européennes ou françaises ?
Pour mémoire, il existe 2 normes internationales (ISO) concernant le format des documents : ODA et SGML.
[^] # Re: C'est une norme !
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
En français, nous avons deux mots : norme et standard.
Le standard est décrété par le fabricant - Modèle standard.
La norme est publiée et gérée par un organisme indépendant de ceux qui l'appliquent.
Le W3C comme OASIS publient des normes, Le PDF est un standard créé et géré par Adobe.
Je ne parle pas des standards des documents Microsoft, le seul à ma connaissance qu'ils ont publié, le RTF n'est pas respecté.
[^] # Re: C'est une norme !
Posté par Matthieu Moy (site web personnel) . Évalué à 0.
Euh, faudrait se renseigner un peu et arrêter le FUD, non ?
[^] # Re: C'est une norme !
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: C'est une norme !
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
PbPg pourra sans doute en rajouter quelques autres, j'imagine.
[^] # Re: C'est une norme !
Posté par Mes Zigues . Évalué à 1.
standard de jure (ayant valeur juridique) pour les normes officielles (AFNOR, ISO, CEN, DIN, BSI, JIS...)
standard de facto pour les textes produits ailleurs (soit par un consortium - OASIS, W3C... dans ce cas on va plutôt qualifier le standard d'ouvert- soit par un industriel dans ce cas on va plutôt qualifier le standard de fermé).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.