Gilles G. a écrit 411 commentaires

Marrant ça, il a disparu mais il poste quand même aujourd'hui sur emacs-devel:
http://lists.gnu.org/archive/html/emacs-devel/2007-08/msg007(...)

Le bug de date, c'est un point de détail révélateur de la politique de Microsoft.
Le format OOXML a été conçu spécialement pour maintenir des compatibilités avec un seul système.
Pour le bug de dates, on aurait très bien pu s'en sortir en enregistrant la bonne date et en faisant la conversion dans les filtres d'import pour les anciens softs (ceux qui ont le bug). Alors forcément c'est moins simple, mais ils demande une normalisation ISO!!

Le problème principal d'OOXML c'est de demander une normalisation ISO alors que la spécification se tourne clairement vers un seul acteur du marché _et_ qu'il existe déjà une norme ISO.

Je comprends pas. On est sensés tendre l'autre joue?

C'est encore pire que ce que je pensais, en fait Microsoft utiliserai la _même_ solution que ODF parce que c'est la meilleure?

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

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

Troisième possibilité:
C'est important, et il faut améliorer le format ODF. Créer un format qui à le même problème n'avancera à rien.

D'ailleurs, étant donné l'expérience de Microsoft dans le domaine des suites bureautiques, ils seraient les bienvenus pour rendre le format ODF meilleur en expliquant ce qui ne va pas.

Tu t'es pas demande pourquoi est-ce que le soft demande la permission avant de faire une upgrade ? Si c'etait sans aucune perte quel serait l'interet de demander ?

Ben oui, parce que si tu fais l'upgrade complete, tu perds ces elements, et si tu reessaie d'ouvrire ce document dans un ancien Word, ben boum, t'as perdu une partie du formattage.

Attends, je t'arrètes tout de suite là. Si tu ne veux pas upgrader ton document au format docx, ben tu le fais pas, c'est tout!
Et puis le coup de "on est obligés de proposer ça sinon on va perdre une partie du formatage", c'est un peu facile à avancer comme argument. En pratique, avec toutes les suites bureautiques on perd une partie du formatage entre les différentes versions, et sans avoir besoin de réenregistrer, et MS office n'échappe pas à la règle!

Ben au hasard le fait que ceux qui sont derriere ODF sont des entites totalement opposees a MS et qui contrairement a ce qu'elles veulent laisser croire n'auraient pas facilite la tache a MS.

Toi aussi tu fais des suppositions... En fait, on n'en sait trop rien.
Ce que je constate c'est que Microsoft a l'habitude d'enfermer ses utilisateurs... Alors je ne veux pas faire de procès d'intention, mais il y a des antécédents quand même.
Donc une bonne raison pour microsoft de ne pas utiliser ODF c'est d'abord parce que les utilisateurs ne seraient plus prisonniers du format.

>a) Et cette page http://blogs.msdn.com/brian_jones/archive/2007/01/09/specify(...) montre des elements similaires definis par OpenOffice

Aller hop! quelques citations:

Leaving things out of the spec isn't the solution
If you look at section 2.15 in part 4 of the spec, you'll see that there are almost 400 pages of documentation covering 206 elements. I still remember when we first started the documentation of that section. We knew it would be tedious, but the more annoying part was that a good portion of it was for legacy functionality that we would have much rather just left out of the spec. In fact, in Word 2007, when you take a .doc file and upgrade it to .docx we ask you if we can do a full upgrade so that all of those legacy settings are removed.

Comme quoi, c'est possible de convertir les documents plutôt que de conserver des parties non documentées. Je suis pour ma part convaincu qu'un format ISO ne devrait pas s'appuyer sur des parties non documentées.

D'un autre coté, l'auteur n'explique pas _pourquoi_ microsoft à eu besoin d'un nouveau format. Si tu as un document là dessus, je suis preneur.
Je pense que le plus simple aurait pu être de contribuer à l'évolution du format ODF. En effet, ce format peut évoluer. Par exemple, pour les formules des tableurs, il s'agissait d'une omission. OpenOffice et Koffice se sont arrangés pour définir ça de manière cohérente et maintenant c'est dans la version 1.1 de la norme (je crois).

-------Ceci est un message d'erreur: Mauvaise foi détectée-------
Monsieur,
comme le montre votre commentaire ici
http://linuxfr.org/comments/818965,1.html
vous savez très bien que cette phrase:

Donc si l'on prend un equivalent OpenOffice.org ouvre exactement de la meme facon les fichiers ODF sur toutes les plateformes supportes ce qui est une legere difference tout de meme

est fausse.
Par ailleurs, je vous invite à relire les commentaires de
http://linuxfr.org/comments/818902.html
qui montrent bien que tout n'est pas parfait dans OpenOffice pour la question du multiplateforme.

Un conseil: nuancez vos propos, ils en seront d'autant plus crédibles.
-------Fin du message d'erreur---------

Effectivement, je me rends compte que c'est la présence des automatic-styles dans le fichier content.xml qui m'a fait penser à un mélange fond/forme.
Mea culpa donc.
(en fait, je pense que cet a priori vient aussi de ce journal http://linuxfr.org/~ginkyo/19715.html )

Pour ce qui est de l'interopérabilité KWord/OpenOffice, je teste effectivement avec KWord 1.6, mais KWord utilise OpenDocument *par défaut* depuis la 1.4! Enfin bon, vivement KWord 2.0 quand même. Je lis régulièrement le blog de Thomas Zander, et je pense que KWord est sur la bonne voie.

Bonjour,
je ne sais pas exactement ce qu'il en est de l'implémentation dOOXML et a vrai dire, je m'en fous...

Par contre le format OpenDocument m'intéresse beaucoup plus car il est utilisé par KWord et OpenOffice (entre autre), et surtout parce qu'il est sensé permettre une vraie interopérabilité.

Je constate que ce format n'est manifestement pas implémenté correctement dans ces 2 suites bureautiques majeures (qui ont d'ailleurs contribuées à l'écriture du standard). En effet, ouvrir avec KWord un document ODT créé avec OpenOffice est plus que périlleux: la plupart du temps toute la mise en page se fait pourrir et les polices ne sont pas respectées...
Pour l'intéropérabilité et la pérennité des documents, je trouve que ça fait un peu limite: comment convaincre un sceptique que ODT saimieux quand manifestement l'échange de document MSOffice<=>OpenOffice se passe mieux que KWord<=>OpenOffice ?

Alors bon, critiquer Microsoft c'est facile, mais la situation du coté du libre n'est pas franchement brillante non plus. D'autant plus que le standard OpenDocument est sorti en version 1.0 en mai 2005.
Enfin, OpenDocument permet normalement la séparation du fond et de la forme (fichier content.xml et style.xml), mais en pratique, les deux suites bureautiques mélangent allégrement le tout et ça, même si c'est un problème d'implémentation, c'est vraiment dommage.

Voilà, c'était mon petit coup de gueule du matin!
Ne vous méprenez pas, je suis quand même partisan d'OpenDocument. C'est juste que la déception est grande quand on voit ce que promet OpenDocument et ce qu'on a réellement.

PS: En ettendant, j'utilise LyX! (mais ça ne permet pas tout ce que fait un traitement de texte)

Oui... Enfin poser une question sur la qualité de windows en utilisant le nom windaube, ça donne un peu l'impression que tu as un a priori!

--
Et sinon, elle est comment la nouvelle C5 de chez citromerde?

Si vous avez un ami intégriste de la ligne de commande

Alors il écrit directement en plain TeX. Non?

Ouais, enfin pour quelqu'un qui ne sait pas (et se fout de savoir) comment fonctionne une page web, le système enregistrer la page de konqueror n'est pas intuitif du tout.
En effet, pourquoi est-ce que les images ne feraient pas partie de la page web?

Dans ce contexte, je trouve qu'un comportement correct serait de proposer, lors de l'enregistrement d'une page web:
* enregistrer la page sans les images (*.html)
* enregistrer la page complète (*.war)

Ma copine par exemple, lorsqu'elle veut enregistrer une page web, elle utilise firefox, parce que "avec konqueror ça marche pas".

L'incompréhension provient peut-être du fait que vous ne parlez pas de la même chose...
IsNotGood pense que le niveau des jeunes d'aujourd'hui n'est pas forcément pire que celui d'il y a 20 ans.
Vous dites que le niveau des jeunes du lycée est pire qu'il y a 20 ans.

Ce n'est pourtant pas la même chose!

Il y a 20 ans, plein de gosses s'arrêtaient en 3ème parce qu'ils n'avaient pas le niveau pour entrer au lycée. Ces gamins ne venaient donc pas "perturber les statistiques" du lycée. Aujourd'hui ces mêmes gosses se retrouvent au lycée avec les mêmes problèmes que ceux qu'auraient eu les gosses d'il y a 20 ans, simplement ça se voit plus!
Allez demander aux gens dans la rue d'additionner des fractions ou de trouver le COD dans une phrase et vous verrez que les vieux ne sont pas meilleurs que les jeunes.

Il n'en reste pas moins que le niveau au lycée baisse, mais c'est peut-être tout simplement parce qu'on veut que le plus de monde possible obtienne le bac; il est peut-être là le problème finalement.

À quand un système éducatif qui ne laisse pas la moitié des élèves sur le banc de touche?

Pourquoi tu l'aides?
Lorsque tu contribues à Whaou, tu n'augmentes pas sa liberté, au contraire.
Si tu lui dis:je veux bien t'aider, mais sous linux seulement, tu lui donnes la possibilité d'augmenter sa liberté.

Chez KDE aussi, ils ont commencer par essayer scons pour KDE4, et finalement ils ont choisi cmake (plus de réactivité des développeurs notamment...)

C'est vrai que tu bosses sur le noyau toi!!

Merci pour l'info en tout cas.
Si j'ai bien compris, le noyau Vista est de l'ordre de taille du noyau Linux donc...(en lignes de code) ?

C'est vrai que ce genre d'attitude est rare...
C'est pas comme si les geek étaient des trolleurs professionnels!

Donc bon les ubuntutistes qui défendent ubuntu aveuglément, ça doit être aussi rare qu'un vimiste qui conseille vim à un emacseur...

Pour etre tenu par les clauses de la GPL , il faut entrer en contact avec le code

Je pense que tu voulais dire il faut distribuer le programme (sous forme source ou binaire, c'est égal...)

Aaaarghhh!!!!
...
Pas mieux. Je passe.

ça a l'air vraiment bien Lisaac! Il faudra que je m'y essaie un jour...

Merci pour cet exemple de code.
Par contre, peut-on avoir une (courte) explication sur la signification des symboles "+", "-", "<-"(ou un lien qui explique tout ça)?

J'ai jamais essayé D, mais je ne suis pas sûr que ça apporte grand chose par rapport à Java en fait (je ne demande qu'à être convaincu ceci-dit).

En fait, j'avais envisagé java, mais on peut pas écrire une librairie partagée appellable depuis du C en Java...
Et au niveau perf, Java et D ça n'a rien à voir. D est très proche de C++ au niveau performances [1].

[1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)

Et alors, comme je suis débutant, je me suis tapé le fameux bug de définition de template
vector<vector<double>> mat;
C'est du vécu. Et le compilateur borland plante avec un message d'erreur qui ne t'aide pas du tout, et comme je suis débutant j'ai au départ cru qu'on ne pouvait pas mettre un vector à l'intérieur d'un autre vector!
Il a fallu que j'utilise g++ pour comprendre...

Et puis c'est un peu facile de dire que j'utilise mal le C++. Moi, j'ai plutôt l'impression que c'est le C++ qui est difficile à utiliser!
Comment se fait-il que j'arrive à programmer en D alors qu'en C++ j'étais toujours obliger de chercher de l'aide sur internet?

Attention: je ne prétends pas que le C++ est un langage pourri. C'est juste que c'est un langage pour spécialiste, pour les gens qui font que ça toute la journée.

Pour les autres il y a Python ;-) ...ou D.

Oui, mais si tu fais ça, les performances s'écroulent vite...

Tu trouve pas ça bizarre de devoir mettre comme signature de fonction MaFonction(int* v) lorsque tu vas utiliser v? Personnellement je trouve ça complètement incohérent. Je déclare v comme un tableau d'entier, mais finalement son type c'est pointeur d'entier!
Et pour celui qui va relire la fonction MaFonction c'est chiant parce qu'il ne peut pas savoir ce qu'est v sans lire le corps de la fonction.