Vous avez probablement entendu que Microsoft Office 2007 SP2 permettait le support de ODF et bien sur, comme personne ne s'y attendait sur ce site site je suppose, nous avons droit a un magnifique "Embrace and extend" de la part de Microsoft. C'est à dire que Microsoft Office 2007 SP2 ne peut ouvrir que les ODF crées par Microsoft Office 2007 SP2 et inversement les ODF crées par ce logiciel ne sont pas compatible avec aucun des autres logiciels se servant de ce format que ce soit GoogleOffice, OpenOffice.org, symphonie etc.
La situation n'est pas totalement rose au niveau de l'interopérabilité entre toutes les versions mais la c'est carrément le pire et un superbe retour en arrière. La raison en est bien simple le document analysé par Rob Weir est une feuille de calcul tableur. Microsoft a choisi d'implémenter la norme ODF 1.1 qui, comme tout le monde le sait, avais un manque de définition de la façon dont les formules sont définis (c'est connus, référencés et fait de façon volontaire le temps de faire une norme propre openformula qui sera utilisé dans ODF 1.2). Comme les autres suites offices ne sont pas totalement stupides, même sans définitions, ils ont implémentés de la même façon cette partie là, se servant de OOo comme implémentation de référence et par la suite du brouillon ODF 1.2 (kspread a des difficultés pour lire les fichiers utilisant le brouillon ODF 1.2 mais vu que c'est l'ancienne version 1.6 qui est testé donc le test ne rime pas à grand chose car il n'est plus maintenu, tout les efforts se portant sur koffice2).
Une des phrases "amusantes" de l'analyse et qui montre bien la méthode utilisé:
This namespace is not what OpenOffice and other ODF applications use. It is not the ODF 1.2 namespace. It isn't even the OOXML namespace.
Je vous laisse lire l'article il est assez instructif et amusant surtout les derniers paragraphes...
http://www.robweir.com/blog/2009/05/update-on-odf-spreadshee(...)
# Doh!
Posté par Larry Cow . Évalué à 10.
C'est du FUD le plus complet, cf. le journal préalablement posté sur le sujet. J'ai fait quelques tests rapides, et MSO2007 a ouvert sans aucun souci plusieurs des ODF (texte et tableur) que je lui ai fourni.
et inversement les ODF crées par ce logiciel ne sont pas compatible avec aucun des autres logiciels se servant de ce format que ce soit GoogleOffice, OpenOffice.org, symphonie etc.
Même remarque. La compatibilité est moins bonne en ce sens (objets OLE qui ne sont pas re-convertis, apparemment), mais ça fonctionne tout de même de manière épatante.
Je ne suis pas franchement pro-Microsoft, mais j'aimerais que la compatibilité entre OOo et Koffice (par exemple) soit du niveau de ce que j'ai pu constater entre MSO2007 et OOo3.
[^] # Re: Doh!
Posté par Anonyme . Évalué à 5.
Feel free to download a zip of all of the test spreadsheet files. The file names should be self-explanatory.
http://www.robweir.com/blog/attachments/Maya.zip
et n'hésite pas à nous donner le resultat de tes tests avec les mêmes fichiers.
[^] # Re: Doh!
Posté par Larry Cow . Évalué à 3.
pouvoir se scripter très bien), mais ça fait dégueulasse. M'enfin déjà, avec des noms de fonctions pas pareils des deux côtés (MSO qui utilise TODAY() là où OOo utilise le très local AUJOURDHUI()), ça finira forcément par coincer. Mais c'est vrai que ça ressemble presque à un oubli, tellement c'est gros.
Autant je conseillerais volontiers le SP2 aux accros de 2007 pour tout ce qui est Word, autant je vais y aller avec un peu plus de prudence pour Excel. Merci de l'info.
Au vu de mes précédents tests, ça confirmerait l'idée que MSO, s'il ouvre bien "directement" les documents simples, convertit de manière irréversible certains types de contenus - formules, graphiques OLE. C'est dommage.
[^] # Re: Doh!
Posté par Anonyme . Évalué à 3.
Petite remarque OOo utilise AUJOURDHUI ou TODAY suivant ta locale justement. Donc si ton système est en français cela sera AUJOURDHUI si c'est en anglais cela sera TODAY et il me semble bien que ce comportement (à mon avis idiot ou du moins pas pratique mais bon c'est pour simplifier madame michu) est le même pour Microsoft Office (ou du moins l'était). C'est la même chose pour SUM et SOMME etc.
[^] # Re: Doh!
Posté par Elfir3 . Évalué à 3.
Maintenant, qu'en est-il des ODF ouverts avec OOo en locale francophone mais écrits en locale anglophone ? Idem pour MSOffice ?
[^] # Re: Doh!
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Doh!
Posté par benoar . Évalué à 6.
[^] # Re: Doh!
Posté par Anonyme . Évalué à 3.
First, we might hear that ODF 1.1 does not define spreadsheet formulas and therefore it is not necessary for one vendor to use the same formula language that other vendors use. This is certainly is true if your sole goal is to claim conformance. If your business model requires only conformance and not actually achieving interoperability, then I wish you well. But remember that conformance and interoperability are not mutually exclusive options. An application can be conformant to a standard and also be interoperable, if you use the legacy formula namespace and syntax. So the desire to be conformant is not an excuse for not also being interoperable, or at least not a valid excuse. One might also wryly note that Microsoft has several Directors of Interoperability, not Directors of Minimal Conformance, and they workshops are called Document Interoperability Initiatives, not Minimal Conformance Initiatives. The difference between minimal conformance and interoperability is well illustrated in these tests.
et aussi:
We might also hear concerns that supporting other vendors' ODF spreadsheet formulas cannot be done because this formula language is undocumented. The irony here is that the formula language used by OpenOffice (and by other vendors) is based on that used by Excel, which itself was not fully documented when OpenOffice implemented it. So an argument, by Microsoft, not to support that language because it is not documented is rather hypocritical. Excel supports 1-2-3 files and formulas and legacy Excel versions (back to Excel 4.0) neither of which have standardized formula languages. Why are these supported? Also, the fact that the Microsoft/CleverAge add-in correctly reads and writes the legacy ODF formula syntax shows not only that it can be done, but that Microsoft already has the code to do it. The inexplicable thing is why that code never made it into Excel 2007 SP2.
[^] # Re: Doh!
Posté par benoar . Évalué à 3.
Bah, il me semble que c'est un peu le but de MS : ils n'en ont rien à foutre de l'interopérabilité, ils voulaient juste faire taire ceux qui criaient à la fermeture de leurs formats. Ils ont normalisé OOXML à travers l'ISO, alors que ça a été la pire normalisation qui ait existé.
Bref, c'est juste pour la forme : MS Office 2007 supporte ODF, c'est génial, et personne n'ira lire les critiques de sombres personnalités qui pourfendent son monopole et ses méthodes.
[^] # Re: Doh!
Posté par jeffcom . Évalué à 0.
pBpG ne répondra rien : la dénonciation du fud a déjà été commise au premier commentaire
[^] # Re: Doh!
Posté par Anonyme . Évalué à 2.
Il semblerait bien que cela ne soit pas un FUD mais, malheureusement, la réalité. Qui plus es dans le deuxième commentaire tu as tous ce qu'il faut pour vérifier par toi même si tu doutes des résultats de Rob Weir et faire comme Larry Cow constater la chose...
De même tu es le bienvenue pour donner le résultat de tes propres tests.
[^] # Re: Doh!
Posté par thedude . Évalué à 7.
On t'as dit 1000 fois que ne pas avoir les formules dans un format bureautique est completement con, tu t'es borne a repondre que c'etait pas grave, que ODF 1.2 arrivait que ca allait tout roxoriser des mamans ours.
Resultat, dans l'cul Sun, ou plutot oracle maintenant, ainsi qu'IBM, ils ont deconne sur la definition de leur norme et ont donne le baton a MS pour les battre en etant 100% ODF compliant tout en pourrissant l'interop office/openoffice. Et ca va etre a leur avantage en terme d'image, MS peut clamer une implem' conforme ODF et rejeter la faute sur OpenDocument que leur format est a chier, nous on a suivi la doc ma bonne madame, vous voyez avec Sun/IBM pour votre probleme avec OO, mais si vous voulez une licence MSOffice, ca vous evitera des problemes.
MS est blanc comme neige et peut se permettre de pourrir en tout liberte l'interop sans rien se faire reprocher.
Chapeau.
Et merci a toi albert de t'etre ridiculise a longueur de debat sur le fait que l'absence de formules dans ODF n'etait pas genante.
[^] # Re: Doh!
Posté par jeffcom . Évalué à 3.
En clair : je voulais faire de l'humour anti-pBpG primaire mais visiblement ça a merdé.
[^] # Re: Doh!
Posté par jeffcom . Évalué à 1.
[^] # Re: Doh!
Posté par Anonyme . Évalué à 1.
[^] # Re: Doh!
Posté par thedude . Évalué à 0.
Je sens un debut de calimeroisme pointer le bout de son nez.
Encore 2 messages et tu vas te plaindre que ce mechant pb pg t'as traite d'ane apres que tu aies fait l'ane.
Allez, encore qq messages comme ca, et tu pourras te creer un nouveau pseudo et nier que tu aies jamais ete Nicolas, puis Albert, puis ____, pour finir par invoquer de soit disante menace d'un denomme spermato contre ta famille ya pres de 10 ans.
Et y croire en plus.
Mouarf.
Ph34R Sp3rM4t0!!
[^] # Re: Doh!
Posté par Bozo_le_clown . Évalué à 4.
Si tu pouvais penser à mon petit chèque parce que les temps sont durs en ce moment.
Merci.
[^] # Re: Doh!
Posté par Bozo_le_clown . Évalué à 1.
1- Est-ce que les formules sont définies dans ODF1.1
2- Dans la négative, MSO exporte sa formule dans une balise, c'est déjà pas mal.
Il ne va pas la traduire dans toutes les versions des outils qui supportent ODF1.1 si elles implémentent toutes une version différente et que ca n'est pas défini dans la norme.
Il vont quand même pas faire un menu
"Export to ODF OO"
"Export to ODF Koffice".... et tous les tableurs de la création
C'est quand même à celui qui veut se rendre compatible de fournir l'effort s'il veut s'intégrer, non ?
Ou alors il fuat combler les manques sur ce point au niveau du standard (peut-être déjà fait avec une version de norme en cours de standardisation)
[^] # Re: Doh!
Posté par Anonyme . Évalué à 2.
1 - tu aurais du lire le lien fournit dans le journal tu as les réponses à toutes tes questions.
2 - Qu'aurais dit les utilisateurs de Microsoft Office si OpenOffice.org, clariswork ou choisi la suite office que tu veux sauvegarde les .xls en changeant la façon dont les formules étaient? Je rappelle qu'il a fallu a tout ce beau monde faire du retro-ingeieneurie pour savoir ce qui se passait dedans... Pour ODF les formules sont maintenant défini ou presque et c'est dans le brouillon de la norme ODF 1.2 utilisé a peu près par toutes les mises à jour récente des suites... Et comme déjà mentionné au dessus, Rob Weir fait bien remarquer que Microsoft était pertinnemment au courrant de comment cela été fait dans OOo et dans les autres suites se servant de ODF, y compris leur propre plugin Cleverage qui est incompatible avec le nouveau truc...
[^] # Re: Doh!
Posté par TImaniac (site web personnel) . Évalué à 3.
Partant de là, ils avaient le choix entre :
- essayer d'être compatible avec OOCalc & co en implémentant un brouillon qui risque de bouger.
- être compatible avec les formules Excel 97->2003 qui ne sont pas prêt de changer et qui représente 90% des documents en circulation.
Rien ne leur étant imposé, à leur place j'aurai fait exactement pareil.
Fallait pas pondre un standard à la rache pour se plaindre après.
[^] # Re: Doh!
Posté par Anonyme . Évalué à 3.
Quel surprise...
Pour le reste que dire si ce n'est OOXML implémenté à l'état de brouillon dans Microsoft Office 2007 et toujours pas en version final malgré le fait que cela fait 1 an et demi que cela a été accepté comme norme par l'ISO...
Tentes donc d'expliquer cette logique que nous rigolions un petit peu cela fera du bien à tout le monde puisque il parait qu'il faut rire 30 minutes par jour!
[^] # Re: Doh!
Posté par Bozo_le_clown . Évalué à 3.
Pour le reste que dire si ce n'est OOXML implémenté à l'état de brouillon dans Microsoft Office 2007 et toujours pas en version final malgré le fait que cela fait 1 an et demi que cela a été accepté comme norme par l'ISO...
Tu as raison, change de sujet pour esquiver.
Quel surprise...
Et dans 10 posts, tu viendras hurler au scandale pour cause d'attaque "ad hominem".
Tiens t'en aux faits , STP
[^] # Re: Doh!
Posté par Bozo_le_clown . Évalué à 2.
1 - tu aurais du lire le lien fournit dans le journal tu as les réponses à toutes tes questions.
Dsl, je suis francophone et pas très à l'aise avec la langue de Shakespeare sinon je trollerais sur /.
Donc de ta réponse, j'en déduis que les formules ne sont pas pas encore dans la norme et que M$ devrait implémenter les plugins de toute la création.
M$ est en position dominante mais c'est à lui de faire l'effort pour que les autres le concurrence.
Dans quel monde vis-tu ?
En plus, ils produisent un export vers un format standard concurrent du leur (ODF ressemble plus à OO aux dernières nouvelles), au delta près des formules qui ne sont pas dans la norme; le support est plus que correct si on en croit les témoignages ici, mais ils n'en font pas assez.
Comment dire ? Non rien.
# ODF 1.2
Posté par vida18 . Évalué à 7.
# De l'importance d'un test normalisé
Posté par goom . Évalué à 6.
Il me semble que non ce qui laisse la porte ouverte à la dérive à laquelle on est en train d'assister et qui va finir comme d'habitude en un pourrissement du format odf 1.1 par MS
Il faudrait vraiment des fichiers types pour approuver la capacité d'un logiciel à manipuler les formats ODF 1.1
[^] # Re: De l'importance d'un test normalisé
Posté par Anonyme . Évalué à 2.
http://odftoolkit.org/
Par contre je ne pense pas que cela concernera ODF 1.1 mais uniquement ODF 1.2 qui comme dit au dessus devrait être incessamment sous peu une norme OASIS.
[^] # Re: De l'importance d'un test normalisé
Posté par pasBill pasGates . Évalué à 8.
Le fait est que la derniere version officielle du standard est 1.1, et qu'elle ne definit pas les formules. Partant de la, MS supporte la derniere version standardisee d'ODF, et supporte les formules en accord avec le standard.
Vous voulez vous plaindre de quoi ? Qu'ils ne supportent pas encore la version non finalisee d'un standard ? Ca sent legerement la mauvaise foi.
Si vous voulez vous plaindre, plaignez vous aux gens qui ont laisser ODF etre standardise sans un element essentiel du format.
Je vous laisse jeter un coup d'oeil aux precedents trolls d'il y a qqe mois sur ODF/OOXML ou plusieurs d'entre vous disaient que c'etait pas important d'avoir les formules standardisees dans un format bureautique...
[^] # Re: De l'importance d'un test normalisé
Posté par Anonyme . Évalué à -1.
Tu devrais aller écrire sur son blog pour lui dire que ce n'est qu'un gros idiot qui ne comprend rien à rien. Bien que toi tu sais pas lire. Car si tu savais lire tu aurais vu (mais c'est peut être un problème d'interface chaise clavier?) que je n'ai absolument pas dit que Microsoft ne supporté par le format ODF 1.1 mais qu'il l'avait fait de tel sorte à être incompatible avec tous les autres logiciels qui se servent de ce format y compris leur propre plugin.
[^] # Re: De l'importance d'un test normalisé
Posté par Bozo_le_clown . Évalué à 0.
mais qu'il l'avait fait de tel sorte à être incompatible avec tous les autres logiciels qui se servent de ce format y compris leur propre plugin.
Tu veux dire qu'ils l'ont fait à minima parce que ca ne fait pas partie de leur priorité d'investir des ressources pour favoriser la concurrence.
Vilains capitalistes !
Au fait, ces balises msoxl: elles sont pas exploitables par des logiciels tiers ?
C'est donc qu'ils auraient pu faire pire en ne les sortant pas, non ?
[^] # Re: De l'importance d'un test normalisé
Posté par Adrien . Évalué à 4.
Il semble que dans cette histoire Microsoft utilise le support de ODF comme un argument marketing, mais pas tellement en vue d'améliorer l'interopérabilité avec les autres suites de bureautique…
[^] # Re: De l'importance d'un test normalisé
Posté par e-t172 (site web personnel) . Évalué à 3.
[^] # Re: De l'importance d'un test normalisé
Posté par thedude . Évalué à 1.
Ben faut dire, Sun l'utlise aussi comme argument marketing, parce qu'une norme en carton qui definit pas les formules, on imagine bien ce que ca donne.
Ah ben non, en fait, on imagine pas, on regarde ce que ca donne: un gros bordel.
[^] # Re: De l'importance d'un test normalisé
Posté par Anonyme . Évalué à 3.
De plus je ne vais que citer Rob Weir et donc si tu n'es pas d'accord va donc troller sur son site et va te foutre de sa gueule et le traiter d'incompétent:
Of course, I am not that cynical. I was taught to never assume malice where incompetence would be the simpler explanation. But the degree of incompetence needed to explain SP2's poor ODF support boggles the mind and leads me to further uncharitable thoughts. So I must stop here.
[^] # Re: De l'importance d'un test normalisé
Posté par pasBill pasGates . Évalué à 5.
a) Tu confirmes qu'ODF 1.2 ne sera pas pret avant un mois, et qu'il faudra donc passer encore du temps apres ce mois pour tout finaliser
c) ODF 1.1 sert a quoi si il est inutilisable ? Pourquoi est-ce que ODF 1.0 et 1.1 ont ete standardise si ils sont inutilisable ? Tu confirmes qu'ils ont standardise un format inutilisable donc ?
Quand a Rob Weir, on sait tous pour qui il bosse et quels sont ses objectifs(peu de rapport avec l'avancement d'ODF lui-meme, plus de rapport avec l'avancement des parts d'IBM et l'affaiblissement d'Office), inutile d'aller perdre notre temps avec lui.
[^] # Re: De l'importance d'un test normalisé
Posté par thedude . Évalué à -3.
J'ai jamais dit le contraire.
C'est meme tout ce que j'attends de la part de MS.
C'est bien normal, ya une concurrence feroce a ce niveau et Sun/IBM a ete assez con pour donner un bazooka a MS pour qu'il puisse leur tirer dessus.
Le bazooka etant une norme ecrite a la rache avec pour seul but d'aller plus vite que MS.
Resultat on a un format qui ne formatte rien du tout, et c'est le bordel.
Mais bon, je te connais, ton cerveau paranoiaque va nous trouver une bonne explication bien foireuse comme tu sais les faire, tu vas finir par insulter pb pg gratuitement, venir chialer qu'il est mechant avec toi parce que t'es trop con.
Et tu vas chier sur tous ceux qui osent relever que ce qui se passe est normal vu qu'ODF 1.1 ne specifie rien pour les formules et que donc MS fait ce qu'il veut, en plein respect de la norme.
PS: Contrairement a toi, rob weir est pas incompetent, meme surement tres loin de l'etre.
Par contre, comme toi, il est ultra oriente. Sauf que lui il a une raison pour l'etre, il s'est investi dans ODF. Toi tu fais juste troller comme un con qui sait pas reflechir tout seul et repete ce qu'il lit a droite a gauche.
[^] # Re: De l'importance d'un test normalisé
Posté par Anonyme . Évalué à -2.
Et non tu ne me connais pas. Par contre dans la plupart de tes messages comme dans ceux de ton alter-ego pbpg on voit bien a quel point vous êtes aveuglé par votre compagnie ou une des ses succursales et êtes prêt a insulter toutes les personnes venant un tant soit peu montrer son "bon" coté...
Ce que tu dis est idiot. Un exemple: sur dlfp les intervenants écrivent en français et pourtant cela n'est "normalisé" nulle part. Ils auraient le droit et la possibilité d'écrire en turc ou en yiddish voir en klingon mais personne ne le fait et pourquoi? Par souci d'interaction et d'inteopérabilité. Microsoft en faisant cela a décidé de parler en klingon...
[^] # Re: De l'importance d'un test normalisé
Posté par thedude . Évalué à 4.
La prochaine etape c'est insulter pb pg, ce qui ne saurait tarder, et faire ton calimero que personne t'ecoutes parce que t'es trop con.
Au lieu de beugler partout que rob machin a ecrit truc et d'etre le petit soldat de sun obeissant sans reflechir, montre nous un peu de reflexion personnelle, chose que t'as ete incapable de faire depuis que tu postes ici sous le pseudo de ~Nicolas.
Commence par nous expliquer pourquoi ODF 1.0 et 1.1 sont sortis sans rien specifier pour les formules.
Quel est l'interet d'une norme sur les formats de suites bureautique sans le format de tableur?
Je sais pas, c'est un peu comme si MPEG-4 etait sorti en disant: bon, pour la video, on est ok, pour le son, on retourne bosser et on revient dans 3 ans avec un truc.
Ensuite explique nous pourquoi MS aurait du se taper une compatibilite avec une demi douzaine de suites ayant toutes leurs petites specificites.
Et pour finir tu nous expliqueras comment MS fait pour implementer un truc qui est encore a l'etat de draft au moment de la sortie de son SP, sachant que Sun/IBM sont bien evidemment pret a changer la specs apres la sortie du SP pour faire la nique a MS.
[^] # Re: De l'importance d'un test normalisé
Posté par campagnard . Évalué à 3.
Le petit soldat d'Oracle, stp !
[^] # Re: De l'importance d'un test normalisé
Posté par pasBill pasGates . Évalué à 2.
C'est vrai que t'es super bien place pour parler d'insultes et d'attaques personnelles :
http://linuxfr.org/~___/27922.html
Je me demandes vraiment comment tu arrives a te regarder dans le miroir le matin, tu n'as donc vraiment aucune ethique ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: De l'importance d'un test normalisé
Posté par Yvan Joffre . Évalué à 1.
# La bonne question étant…
Posté par Anonyme . Évalué à 7.
Est-ce que MS va se contenter de leur support de ODF 1.1 et rester avec leur version pour les formules, ou est-ce qu'ils vont jouer le jeu et implémenter correctement la nouvelle version ?
Les paris sont ouverts… pour ma part, je pense qu'ils resteront avec le support 1.1 en clamant « on est compatible ODF » alors qu'en fait, pas vraiment.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.