J'ai pas compris le début de commentaire en réponse à moi (enfin, je vois pas le rapport, mais je pense qu'il manque un début de phrase)(jusqu'à la question)
Question: ca te rapporte quoi de defendre le microsoft et son format? Pbpg on comprend il est paye par la boite pour fudder/troller ici mais toi?
Ça ne me rapporte rien. J'aime bien lire ce qu'on me propose et montrer les fautes qui se trouvent là-bas. En plus j'ai du temps à perdre. Mais toi, ça te rapporte quoi de fudder/troller ici ?
The following organizations have participated in the creation of this Standard and their contributions are
gratefully acknowledged:
Apple, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, Toshiba, and
the United States Library of Congress
Mais comme MS a acheté toutes ces firmes, ça ne fait qu'un seul.
Le mot entre faile et compliqué, c'est normal, ou intermédiaire. Imaginons que tu joue à un jeu, par exemple de course, et que tu doive réaliser un chrono en dessous d'un certain seuil pour passer au niveau suivant. Pour toi, on passerait immédiatement d'un seuil "facile" à un seuil "compliqué" ? (rapelle-toi ces jeux... easy - medium - hard, facile - moyen - compliqué...)
"On s'emmerde a faire ca", parfois, ça m'emmerde de faire des choses, même si ce n'est pas compliqué à faire. Par exemple, là, je dois aller faire des courses, et ça m'emmerde. Pourtant, c'est pas très compliqué.
Ça ne veut pas dire que c'est compliqué. On s'imagine bien que ce n'est pas facile de changer de format de données, ça se fait pas en 3 secondes et demi. Mais cette phrase ne veut pas dire que c'est compliqué.
Eisler, who just came on board Microsoft's Mac Business Unit in June, did not give an explanation for the schedule slip.
Là il l'a pas dit.
Elsewhere, however, he was quoted as saying Apple's 2006 switch to Intel processors and the ensuing need to move to different development tools, as well as the ongoing struggle with the new Open XML file formats, played parts.
Et là il dit que le retard de la sortie est due au passage à de nouveaux outils pour le passage au mac intel, et au fait qu'il fallait implémenter le nouveau format. Il est marqué où qu'il dit que c'est difficile ?
A partir d'une série d'idée tu tires une conclusion qui t'arrange : "Le format est difficile à implémenter". Je te propose une conclusion alternative : "Microsoft n'a pas envie de rendre sa suite interopérable". Tiens, ça marche aussi. Je pense qu'on doit pouvoir en trouver d'autres.
La version 1.3 alors. L'argument "euh oui mais dans 3 ans c'est possible que ce soit plus normalisé" est valable dans les deux camps. C'était juste pour montrer que l'argument plus haut est débile.
Ça ce n'est pas vraiment une preuve.
"La recette d'un cordon bleu est librement implémentable, et ce n'est pas très difficile à faire."
"Faux, car untel ne l'a pas fait." n'est pas un argument valable. Sinon je peux dire pareil pour le format ODF car il n'est pas implémenté dans Office Mac.
<table:table-cell office:value-type="float" office:value="12345678910.1235">
donc bon... ce que tu nous montres là plus haut est de type : office:value-type="string". J'espère bien qu'il n'arrondit pas le texte. Mais merci pour cette contribution amusante.
Ce qui ne change pas le fait que ce soit un défaut (ou non) d'implantation et non pas un défaut du format.
Qu'elle est le comportement que je prefere a ton avis? Dans mon cas et c'est tout personnel je prefere les logiciels qui font ce que je leur dit de faire (quitte a aller dans les preferences change la precision)
Elle est où cette option ? Je ne la trouve pas. Par exemple dans le cas (plutôt improbable...) où je voudrait 25 chiffres significatifs.
Donc OpenOffice fait exactement comme MS Office, c'est à dire que tous les deux, ils prennent la valeur introduite par l'utilisateur et l'adaptent à leur représentation interne. Ce n'est pas a priori une erreur de ODT ou OOXML, mais de l'implémentation. Donc sur ce coup, il n'y a pas de différence entre OOXML et ODT, mis à part que ODT possède une balise de plus qui précise l'affichage.
De ton côté, tu affirmes que l'auteur a commis une erreur car tu calcules qu'il a modifié 33% du document et non 40% comme l'auteur le dit dans l'étude.
Je me cite :
40% of parts have to change in order to take into account our minor change.
Le minor change en question, c'est la modification de 33% des cellules du document.
Alors soit j'ai de très gros problème de français, auquel cas je m'excuse, soit tu te trompes sur ce que j'ai dit.
Il y a d'autres choses (mais là c'est juste une approximation de ta part, que je voudrais corriger). Tu dis
À la main, il a modifié cette cellule en remplaçant un "3" par un "4" (on passe de 10+20=30 à 10+20=40)
Il passe non pas de 10+20=30 à 10+20=40, mais il supprime la formule "10+20" et note uniquement 40. (heureusement, sinon ça ne veut plus dire grand chose) Et c'est cette suppresion de formule qui doit le faire modifier d'autres documents, dont un qui contient une liste des formules.
Tu peux essayer d'entrer 1234567890.1234567890 et nous donner ce qui est stocké dans office:value ? C'est pour voir si tu as la même version de OpenOffice que moi ;-)
1) Je ne conteste pas le chiffre de 40%, je dis juste que par "minor change" il modifie 33% du contenu de son document. Et ça, pour moi, c'est pas mineur.
2) Je ne chipote pas sur l'étendue de l'imprécision. Je dis juste que ce qu'il dit (1e-5, 1e-4, "but its order of magnitude changes depending on the value") est faux.
Argument 2, le nombre entré n'est pas le nombre stocké. D'accord. Mais ça doit venir de l'encodage des nombres en virgule flottante. Par contre, ça, c'est complètement faux :
Entered value Stored value Rounding error
123456.123456 123456.123456 0
12345.12345 12345.123449999999 o(1e-5)
1234.1234 1234.1233999999999 o(1e-4)
...
Not only there is a rounding error, but its order of magnitude changes depending on the value.
Dans les deux cas, l'erreur est du même ordre relatif, car ~10^(-12)/12345 et ~10^(-13)/1234 me semble des valeurs assez proches. Bah oui, la différence entre 12345.12345 et 12345.123449999999, c'est pas 1e-5, mais 1e-12.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
* non, pas toi, je sais
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
Ça ne me rapporte rien. J'aime bien lire ce qu'on me propose et montrer les fautes qui se trouvent là-bas. En plus j'ai du temps à perdre. Mais toi, ça te rapporte quoi de fudder/troller ici ?
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
Mais comme MS a acheté toutes ces firmes, ça ne fait qu'un seul.
[^] # Re: une excellente analyse de pourquoi microsoft openXML
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
"On s'emmerde a faire ca", parfois, ça m'emmerde de faire des choses, même si ce n'est pas compliqué à faire. Par exemple, là, je dois aller faire des courses, et ça m'emmerde. Pourtant, c'est pas très compliqué.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 3.
Elle est belle celle la!!!!!! Magnifique !
Même les télés en noir et blanc avaient du gris.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 1.
Et là il dit que le retard de la sortie est due au passage à de nouveaux outils pour le passage au mac intel, et au fait qu'il fallait implémenter le nouveau format. Il est marqué où qu'il dit que c'est difficile ?
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 1.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 4.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 1.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 3.
"La recette d'un cordon bleu est librement implémentable, et ce n'est pas très difficile à faire."
"Faux, car untel ne l'a pas fait." n'est pas un argument valable. Sinon je peux dire pareil pour le format ODF car il n'est pas implémenté dans Office Mac.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 4.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
donc bon... ce que tu nous montres là plus haut est de type : office:value-type="string". J'espère bien qu'il n'arrondit pas le texte. Mais merci pour cette contribution amusante.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
Elle est où cette option ? Je ne la trouve pas. Par exemple dans le cas (plutôt improbable...) où je voudrait 25 chiffres significatifs.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 1.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 4.
Il y a d'autres choses (mais là c'est juste une approximation de ta part, que je voudrais corriger). Tu dis Il passe non pas de 10+20=30 à 10+20=40, mais il supprime la formule "10+20" et note uniquement 40. (heureusement, sinon ça ne veut plus dire grand chose) Et c'est cette suppresion de formule qui doit le faire modifier d'autres documents, dont un qui contient une liste des formules.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
2) Je ne chipote pas sur l'étendue de l'imprécision. Je dis juste que ce qu'il dit (1e-5, 1e-4, "but its order of magnitude changes depending on the value") est faux.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à -2.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 3.
Dans les deux cas, l'erreur est du même ordre relatif, car ~10^(-12)/12345 et ~10^(-13)/1234 me semble des valeurs assez proches. Bah oui, la différence entre 12345.12345 et 12345.123449999999, c'est pas 1e-5, mais 1e-12.
[^] # Re: OOXML is defective by design
Posté par Nicolas Schoonbroodt . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à -1.
[^] # Re: Cycle de release
Posté par Nicolas Schoonbroodt . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 3.