pasBill pasGates a écrit 16278 commentaires

Oui bien sur.

http://www.cbronline.com/article_news.asp?guid=9F4A0FA2-4757(...)

Ils ont dementi(et le premier ministre aussi) la meme semaine que l'allegation bien entendu et avant le vote.

Mais bien entendu, toi tu sais lequel des 2 dit la verite hein ?

Ben quand t'as 5-7 personnes qui te causent en meme temps et qui contestent toutes le meme point de differentes manieres, ca fait du desordre hein :)

Probablement a peu pres autant experiemental qu'ODF avec KOffice.

Bien au contraire, je l'ai fait, cf. la partie office-settings d'ODF, ca c'est du concret.

cf. http://blogs.msdn.com/brian_jones/archive/2007/01/25/office-(...)

Excel avait un format XML en 2000, avant meme que le site d'OO existe.

Dison qu'un des 2 formats gagne la guerre et que l'autre disparaisse.

Un des 2 cotes va devoir modifier sa suite office en profondeur pour implementer l'autre format, ca coute, ca prend du temps, et pendant ce temps le cote qui a gagne avance ses pions et gagne des marches.

C'est tres tres simple a comprendre en fait, c'est simplement une guerre economique.

Simplement, aucune réponse. ODF se veut être une norme potable, elle laisse la rétrocompatibilité au placard et confie cette tâche à l'application. Ce qui est normal. Embourber une norme de specs vétustes, c'est aller droit dans le mur.

Merci de confirmer qu'avec ODF ces info seraient placees dans office-settings, donc illisibles tout comme avec openxml

Pourtant ODF est ouvert, donc plutot que de dire 'ouinnn OOO fait pas bien, donc OOXML peut faire pas bien' (tu met sur un meme pied une implémentation et une norme) sort plutot le ou les paragraphes de la norme qui indique 'il faut utiliser des balises spéciales pour la compatibilité' dans ODF.

Oh mais ils ont fait autre chose, ils ont une section, appellee office-settings, ou une application peut stocker ses parametres a elle, et il n'y a rien dans la spec qui limite de quelque maniere que ce soit ce qui y est stocke.

cf. http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-(...)

Enfin je t'apprendrais que meme si on est pas idiot, ou qu'on a plein d'exp, quelquefois, certains choix sont fait de ne PAS respecter à 100% la norme. Quel navigateur respecte à 100% le test d'acid2 ?

Mais moi je t'invites a aller regarder la spec donnee plus haut. La section de la spec dont je parles est _FAITE POUR CA_ : stocker des infos specifiques a une application. Resultat, si l'application ne les documente pas, pan dans les dents.

Effectivement il semble que ce soit documente, me suis donc goure (bien que ce soit introuvable depuis Google si on ne sait pas ou regarder).

Mais ce que je trouve assez fort, c'est que, comme le dit Olivier Faurax, cette option "bizarre" dénoncée par les pro-OOXML a justement été créée pour être plus compatible avec Word...

Pas du tout. On ne denonce rien du tout. Moi je trouves cela tout a fait normal. Ce que l'on denonce c'est que OpenXML soit mis au pilori pour avoir fait qqe chose qu'ODF fait aussi.

Et tu fais comment pour que la moulinette (dans les 2 sens) puisse convertir sans perte sans noter dans le resultat final comment il faut afficher l'element ?

Parce que ca me fait bien marrer cette histoire d'utiliser un filtre/moulinette qui revient a chaque fois, mais personne n'a ete foutu d'expliquer comment cela se ferait techniquement sans perte.

De tout de facon dans le cadre de koffice, la version 1 a toujours etait une version beta et c'est dans la version 2 que l'on verra le support global de ODF. Cette version sortira d'ailleurs avant la deuxieme suite office qui supportera Microsoft OpenXML, Microsoft Office 2008 pour Mac

a) NeoOffice pour Mac supporte OpenXML
b) C'est bien toi qui repetait a tort et a travers que ODF c'est Mieux(TM) parce qu'il y a plusieurs implementations non ? Marrant, a te lire il y a que OO qui lit ODF a peu pres correctement...

Maintenant, si WordPerfect permet des mises en forme spécifiques qui ne sont pas exactement descriptibles en format ODF, utiliser la balise office:settings pour inscrire que l'utilisateur a mis tel paragraphe au format "3DMagicMovingLetters" est une mauvaise utilisation du format, la bonne pratique consistant à réaliser la conversion pour que le document soit le plus proche possible de l'original, tout en intervenant pour enrichir la norme.

Si tu veux ajouter a ODF tous les comportements de toutes les suites office, les 6000 pages d'OpenXML seront un gag compare a la taille d'ODF si tu veux mon avis...

Quand a realiser une conversion la plus proche possible, c'est pas une solution, les gens ne veulent pas perdre le rendu de leur document, si ce que tu leur proposes est une perte, ils t'enverront balader.

Si je comprends bien, c'est l'impossibilité de décrire tous les documents bureautiques possibles avec ODF qui lui est reproché ? La multiplication des normes semble-t-elle une bonne approche pour aboutir à un format universel (si c'est possible) ?

Mais moi je ne lui reproche rien, je trouves qu'il fait les choses normalement, tout comme OpenXML

Ah notre cher Albert qui decouvre que certains parametres ne sont pas utilises et visibles tout le temps, et qui en deduit qu'ils sont donc inutiles tout le temps... Fantastique.

Bon, vu que la reponse initialle etait au mauvais post, on recommence...

Ce qui le prouve c'est le fait que ces elements non-documentes sont dans une parti marquee "compatibilite uniquement", dont l'implementation est optionelle, et que la spec dit clairement que les softs ne sont pas senses la generer pour les nouveaux documents.

Et en ajoutant a ca, on parle de spec ici, l'implementation de la spec c'est les societes qui la font. Si MS voulait foutre la m... rien ne l'empecherait d'utiliser ODF et d'y mettre plein d'elements non-documentes dans office-settings, vous seriez alors bien avances.

Vu que ce qu'ils font est tout a fait normal, pas vraiment. Il n'y a aucun probleme d'implementation, ils l'ont fait correctement.

Vu qu'il n'y a pas de probleme d'implementation(ce qu'ils font est tout a fait normal) pas vraiment.

Disons que intrinsequement il y a peu etre la possibilite de se passer de certaines API specific windows pour implementer la majeur parti du format mais bon Microsoft n'a pas encore trouve le moyen de le faire pour sa propre suite Office sur Mac.

http://trinity.neooffice.org/modules.php?name=News&file=(...)

Support for interoperability with Microsoft Office 2007 Word documents and VBA, as well as the Solver-like module in NeoOffice's spreadsheet, is drawn from the ooo-build project, a branch of OpenOffice.org that includes several features which Sun has not yet integrated into the main OpenOffice.org code.

C'est marrant quand meme, un fork d'OO, en GPL, qui supporte OpenXML sur Mac, et ca date de Mars 2007.

Et tu liras bien attentivament que le support pour Word 2007 va etre directement ajoute a OO lui-meme par Sun.
Preuve assez claire que :
- c'est faisable sur d'autres plate-formes que Windows
- c'est ouvert
- pas de problemes de brevets vu que malgre tout le bruit que certains ont fait ils sont alle de l'avant, en connaissance de cause

Et alors µmou a menacé de fermer leur filiale danoise et depuis le Danemark a continué à payer leurs licences µmou plutôt que de faire des choses utiles .

Ca je te mets au defi de le prouver. C'est un peu simple de reprendre des rumeurs lancees par certains, il faut aussi un minimum d'elements pour supporter l'affirmation.

Tu sais, en devloppement, avant de remettre en cause la conception, on remet en cause le developpement. C'est a dire que si on a un comportement qui ne correspond pas a ce qu'on pensait on dit d'abord 'Est ce que j'ai bien implémenter le truc'.

Oh si, ca demande un boulot enorme, cree un delai de au moins 2 ans, et ca bloque la possibilite de convertir correctement les anciens documents, qui etait la raison meme de l'existence d'openxml.

Mais peut être que Microsoft ne veut simplement pas rendre Office interopérable : il ne veut pas que l'utilisateur ait le choix de lire et d'écrire ses données avec le logiciel de son choix.

Vu qu'OpenXML est ouvert et clairement defini ce n'est pas le cas.

Tu sais, en devloppement, avant de remettre en cause la conception, on remet en cause le developpement. C'est a dire que si on a un comportement qui ne correspond pas a ce qu'on pensait on dit d'abord 'Est ce que j'ai bien implémenter le truc'.

Ben tu vas etre sympa et expliquer a ces pauvres gens d'OO comment faire alors ? D'ailleurs tu devrais donner une explication de la methode a suivre ici, et avec legerement plus de details que "ca se fait dans le filtre", parce que ca ces pauvres idiots de OO, KOffice et MS Office qui n'ont aucune experience et ne savent pas comment faire, ils comprendront pas.

Une norme a besoin de tous les acteurs possibles, chacun apportant son expérience, ses connaissances... Si MS avait voulu participer à l'écriture de l'ODF, il aurait été le bienvenue, je pense!

Oui oui bien sur, tu vis avec Alice au pays des merveilles toi.

Je vais t'apprendre un truc, IBM et Sun fonctionnent de la meme maniere que MS et utilisent les memes tactiques. Si ils peuvent bloquer MS et y gagner, ils le feront(MS ferait de meme bien evidemment).

Mais alors pourquoi, mais oui _pourquoi_ a-t-il fallu écrire un nouveau format?

Parce que, chose dingue, le format c'est legerement plus que ces elements.

PS: je ne suis pas d'accord pour dire qu'intégrer des champs non documentés est une bonne solution...

Ben fais seulement, trouves une meilleure solution :)

Genial, alors tu vas m'expliquer pourquoi est-ce que OO ne convertit pas ses elements relatifs a l'espacement utilise dans OO 1.1 ?

Ah oui, parce que c'est pas faisable sans perdre ses petits en relecture.

Tu jettes un oeil sur cet element genere par OO sur le lien que j'ai donne plus haut, et tu te rendras compte qu'un document ODF qui le contient ne peut pas etre traduit correctement par KOffice, ... car pas documente.

Bref, cela _prouve_ sans contestation possible qu'ODF et OXML ont cette meme caracteristique.

Moi la question que je te pose c'est : comment stocker un format (WordPerfect/ Word 95) dont certains elements ne sont pas clairement definis.

Que ce soit dans ODF ou Openxml, tu fais comment si tu n'as pas d'infos sur la maniere dont l'element est affiche?

Ben oui, dans les 2 cas il faut utiliser un element qui est non documente, vu que la doc n'existe pas, et c'est ce que font les 2 formats, mais pour je ne sais quelle raison, ca gueule pour openxml, et personne ne se plaint pour ODF.