abramov_MS a écrit 2172 commentaires

si niveau assurance on en a deja une. Microsoft a declare la guerre au mouvement open source de facon tout a fait clair, net et precise. Avec des menaces, des association douteuse (GPL = cancer), du FUD, de la manipulation, des marionnettes lancant des attaques legales ou voulant interdire la GPL (SCO soutenu financierement par un de tes boss), de la corruption (Suede), des campagnes de denigrement et de fausse accusation (cf Peter Quinn) pour imposer de facon artificiel des projets (microsoft oxml meme pas encore defini face a ODF dans le massachussetts) etc.

Enfin il est clair que Microsoft de part son histoire, de part ses actes actuels, de par les declarations de ses dirigeants vont tout faire pour empecher le mouvement opensource d'exister. Ca ce sont des certitudes pas et ce sont dons des assurances que faire "confiance" a Microsoft serait la pire des idioties surtout que en plus le format (pour en revenir au sujet) est techniquement pourri et sa definition verbeuse, incomplete, redefini la roue et redondante a une norme ISO deja existante.

tiens toi tu es revenu apres toutes les enormites que tu as sortis hier. Comme quoi en effet le ridicule ne tue pas.

au fait ta spec moi je te l'ai donne
http://linuxfr.org/comments/903579.html#903579

alros tu me le files quand le truc de word97 qui est defini dans la norme ECMA?

et par rapport a ca: http://linuxfr.org/comments/903619.html#903619

tu consideres que des trucs non defini sont plus interoperable cela laisse reveur... Enfin les trucs tel que word97 ou activx c'est vrai que c'est 100% interoperable et que c'est 100% secure...

la nouvelle version est sorti et ils sembleraient que contrairement a ce qui etait dit en novembre ils aient reussi a mettre microsoft oxml des la sortie et non plus lors de la SP. Par contre naturellement c'est la version qui a de grande chance de faire aussi long feu que le format xml 2003 vu que, sauf enorme surprise lors du BRM, si le format microsoft oxml est adopte par l'ISO il y aura pas mal de chose a changer dedans par rapport a l'implementation actuelle...

Sur Windows Mobile, Symbian, ... je peux creer une implementation 100% conforme d'OpenXML.

vas y vas y ca va nous faire des vancances et surtout j'aimerai bien voir le resultat.

Par contre avec ODF, ton implementation elle n'est pas conforme, car il manque un element. Il est techniquement impossible d'implementer un lecteur ODF 100% conforme sur ces OS.

Rate encore mais c'est pas grave tu peux encore jouer.

Java applets are described as native objects in the OpenDocument specification (§9.3.4). This means any full implementations will require a Java Virtual Machine present from within the application. However, conformance to the standard does not require a full implementation.

source wikipedia

Avec ODF, ce soft ne sera pas conforme si il ne supporte pas Java, ce qui disqualifie a peu pres toutes les plateformes mobiles, avec OpenXML pas de contrainte de ce type.

T'as beau le repeter c'est faux.

Va lire des bouquins d'informatique, prends des cours, ... je sais pas, mais apprends la difference entre une implementation et une spec, c'est pas sorcier.

Tu devrais suivre tes conseils au pre-alable surtout que c'est ton metier ce qui n'est pas le cas pour moi :)

donc comme prevu ton microsoft powerpoint avec format oxml tu donnes pas d'exemple sur quoi il fonctionne pour de vrai en dehors de microsoft office 12 et microsoft office 2008 et donc des config plutot muscle (en comparaison avec le OLPC ou le eee qui ont tout deux un support de ODF pour des configs plutot restreinte).

toujours a faire du FUD quoi le pbpg.

Je remarque aussi que tu changes de denomination les choses lorsque cela t'arrange. Si t voulais parler de jVM+framework sur pc il fallait etre precis. Tu as parle de java et je trouve assez rigolo que tu changes la denomination de la techno sun presente sur les telephones portables uniquement pour arranger tes dire.

Tant que j'y suis a marcher dans ton troll je vais relancer un petit peu... Les trucs tel que le activx ca marche sur toutes les plateformes? Parceque cela fait bien parti de la norme microsoft oxml il me semble non?

ah ah ah voyons voir ah oui mon telephone a java a l'interieur et il a vraiment rien comme memoire.

Enfin de tout de facon tu parles de ODT avec Java a l'interieur et que cela est trop lour je pense que le meme argument est tout a fait utilisable pour un document ppt (je connais pas l'extension pour microsoft oxml) avec une video de plusieurs dizaines de megs a l'interieur. Ca marchera pas comme un document ODT avec du java a l'interieur ou une video.

Ton argument sans aucune preuves vu qu'il n'existe aucune implementation de microsoft oxml sur des configs tres legeres est assez ridicule.

ps: va faire tourner un microsoft office 12 sur un pentium 166. C'est pas faisable, OOo ca le fait meme avec java, c'est pas un foudre de guerre loin de la mais cela demarre et est a peu pres utilisable.

sur quel plateorme java n'est pas implementable?

Tu parles de facon bien general sans donner un exemple precis. Java niveau portabilite c'est presque aussi bien que linux et c'est a des annees lumiere de n'importe technos microsftienne.

Pour t'aider a comprendre : Il est possible de supporter OpenXML sur un systeme avec qqe megaoctets de RAM et un cpu peu puissant

j'aimerai bien voir cela...

ODF par contre, tu ne peux pas avoir une implementation conforme, car ton systeme n'est pas assez puissant pour supporter Java.

tiens pourtant mon telephone portable a java dedans et c'est un truc tout basique... Ton "argument" est assez foireux car tu n'amenes strictement aucune preuve de tes affirmations.

Si tu comprenais un minimum l'informatique mon cher, tu aurais compris que MS n'a pas sorti Office pour x64 alors qu'il a sorti Exchange, SQL Server, ... pour x64 car c'est totalement inutile. Personne au jour d'aujourd'hui n'est limite dans son utilisation d'Office par la limite des 4Go de RAM du x86

Mais oui mon cher du coup vous vous tapez des trucs style chroot avec des redondances de librairies etc. Je comprend mieux la dizaine de gigas pour installer un systeme nu Microsoft Vista.

oui oui donc on reprend ta logique:

ODT c'est pas portable car java existe pas partout
microsoft oxml n'existe que sous x86 windows et macos X mais ca c'est portable.

Tu es assez ... surprenant dans tes trolls, mauvais mais surprenant. Parler d'interoperabilite theorique concernant des technos microsoft et se mettre en concurrence avec le logiciel libre ca laisse reveur sur tes capacites d'observation.

Tu balances des trucs comme ODT c'est portable a cause de java. Question stupide: java et ODT existe sous MacOsX x86? java et ODT existe sous Windows x86? java et ODT existe sous linux x86? Si oui tu as deja une plateforme de plus de supporte et ton "argument" est invalide.

Apres j'ai gentiment devie sur le x64 car TU as parle de support sur autre plateforme. Cela me fait rigoler que ta boite soit toujours aussi incapable de sortir des softs x64. Tu veux des exemples d'utilite? Pour un tableur faire des calculs plus precis a oui zut je comprend maintenant ta remarque et pourquoi c'est inutile pour Microsoft Office vu comme excel est doue pour les calculs... :)

ouhais et java n'est n'a pas de documentation et n'a pas de specifiaction? Il me semblait bien que si et meme que java etait GPL du coup java n'est pas limite a une plateforme et par consequent ODT non plus. Donc quel est la difference avec microsoft oxml? Une seule ODT est deja implemente pour plus de plateformes differentes que microsoft oxml.

Qui te dit qu'ils ont essaye ?

Comme d'hab avec ta boite. Bug connu et on s'en tape comme de la premiere version de MSdos.

Les gens insastisfaits ont plusieurs autres options

Ouhais une autre s'appelle OpenOffice.org...

Office Windows et Office Mac ne sont pas les memes produits. C'est pas du tout le meme code, pas les memes developpeurs, pas forcement les memes fonctionalites non plus. Bref, c'est un cas similaire a KOffice<->OO, pas a OO Linux <-> OO Windows

Avec une "legere" difference tout de meme... koffice il y a 3 developpeurs et meme pas a plein temps. Je te trouve tres tres rigolo de comparer un suite office developpe par 3 personnes a temps partiel et une suite office developpe par des centaines a plein temps. Tu veux dire que les devs du libre soit (x*100)% meilleur que ceux de ta boite :)

Ca s'appelle une conversion.

Cela s'appelle une arnaque car encore une fois a la prochaine version de Microsoft Office il va y avoir comme d'habitude des problemes. C'est trop genial vous etes tres tres fort commercialement parlant!

donc en fait aujourd'hui tu attaques ODT comme quoi pas portable car java pas dispo partout alors qu'il existe un microsoft office supportant microsoft oxml dispo sur toutes les plateformes imaginables? Ah non uniquement sur Mac x86 et sur MS windows x86. C'est rigolo il me semble bien que java est disponible pour ces deux plateformes (et meme plus) donc niveau interoperabilite je vois pas franchement le probleme pour ODT par contre pour microsoft oxml il est assez flagrant...

Ouhais champagne vous avez reussi a ecrire un soft pour un deuxieme OS. Heureusement c'est du x86 maintenant.

Et la version native x64 ce sera pour l'annee prochaine?

ODT est clairement pas un format qui a ete concu pour etre un standard a la base, l'inclusion de Java etant l'exemple flagrant vu que cela limite fortement la disponibilite du format sur des plateformes n'ayant pas de JVM decente ou n'ayant pas les ressources CPU/memoire pour faire tourner une JVM en plus du soft qui lit le document ODT.

Ouhais enfin tu parleras de portabilite et de plateformes le jour ou ta suite office qui inclu le format microsoft oxml existera sur autre chose que windows x86... Vous avez toujours pas ete capable de sortir un truc qui fonctionne sur Mac ou sur x64 alros de la a parler portabilite regarde un peu la pourtre dans ton oeil.
Pour le moment microsoft oxml il n'existe que sur une seule plateforme et sur une seule architecture c'est pas franchement brillant.

Tout comme il a toujours ete indique que le support des formules etait incomplet dans Office pour Mac...

Tu veux dire que en 15 ans les quelques centaines de developpeurs Office chez microsoft ont pas reussi a implementer cela???? Ouhaou je suis impressionne!!!!!

Au fait le lien sur ce sujet puis aussi le lien sur le meme truc pour windows car exactement le meme probleme existe dessus ;) (transformation d'un champ equation en image ca fait 15 ans que ca existe et 15 ans que c'est tres chiant).

Avec OO et KOffice c'est pourtant la seule possibilite si tu veux ouvrire tes documents soi-disant standards ODF.

Entre koffice (je sais vraiment pas ce que tu as contre les 3 pauvres developpeurs de cette suite) et OOo c'est presque vrai mais entre OOo et OOo que ce soit sous Unix, sous windows ou sous Mac (x86 ou x64) je recupere exactement la meme chose. Ce qui est rigolo c'est que la meme chose avec MS Office windows ou Mac (seulement 2 petites plateformes supporte) ca marche pas. J'obtiens pas le meme resultat... Ok c'est un peu complexe deux plateformes differentes on va tenter entre windows et windows et deux versions differentes... Ah zut la aussi ca foire ben cest pas de bol tout de meme. Allez tant pis on se contentera de l'ascii pour un echange de document parfait entre deux suites MS Office.

Marrant, j'etais pourtant convaincu que les erreurs se corrigent vu que le standard n'a pas encore ete accepte.

Marrant je me demande comment ca va se passer pour les documents microsoft oxml pre-ISO (si cela passe). Je sens que ca va etre comme avec le fabuleux format xml qui devait tout ecraser de microsoft office 2007): les utilisateurs vont acheter de la vaseline...

et voila encore a raconter des betises... Au moins tu as arrete avec ta demande idiote de definition dans ODF d'un truc qui ne peut pas y etre... c'est deja ca.

ouais leur seule activite ayant ete de mettre des trucs pour "ameliorer" la compatibilite de ODF avec les formats binaires tout pourris de ta boite cela me gene assez peu :)

D'ailleurs ils sont partis avec pertes et fracas parceque jsutement aucune de leurs propositions n'etaient acceptes ce qui me rassure pas mal sur la qualite du format ODF oui :)

ah non moi je predit pas le futur par contre entre j'ai le choix de faire confiance soit a Microsoft, qui a declare la guerre aux logiciels libres, soit a Sun, qui a certes par interet, embrasse le mouvement opensource.

Et tu te demandes a qui je fais le plus confiance? C'est pourtant pas difficile...

tu les aimes beaucoup les 3 guignols de la defunte fondation...

Bon on va pas refaire le troll d'il y a quelques mois donc je te refile le lien cela ira plus vite

http://linuxfr.org/~abramov_MS/25645.html

alors tu sais leur credibilite a peu pres inexistante (merci le w3c) et leur "demonstration" de l'utilite de ces elements polluant dans la norme de ODF n'a jamais ete faite du coup cela ne servait vraiment a rien de les mettre dedans et ce fut avec le recul visiblement une tres bonne decision du comite.

A peu pres autant que ceux qui echangent des documents entre KOffice et OO

Ce qui fait tout de meme beaucoup moins de monde et qui plus est il est bien indique que le support des versions actuelles de koffice pour ODF est incomplet mais cela tu le sais pertinnement.

Si c'est pour lire/editer du texte uniquement, autant envoyer un fichier ASCII plutot qu'ODF.

Tu fais de l'ascii art aussi? Ca doit etre rigolo a lire tes documents...

J'adores ta comparaison, une ou deux erreurs dans les fonctions statistiques compare a un manque total de support pour les formules.

Et oui que veux tu ma formation scientifique me fait preferer un manque que des erreurs. Un manque tu le combles les erreurs tu es dans la merde.

non tu as tort SUN ayant participe a l'elaboration de ODF 1.2 elle sera couverte. Apres pour la version 1.3 c'est un autre question. De tout de facon il est clairement pas dans l'interet de SUN de se retirer de OASIS donc le risque pour la version 1.3 il tend a peu pres vers 0.

bon visiblement comme tu as un leger probleme a comprendre le truc de ODF... Le UseFormerLineSpacing ne fait pas partie de la norme ODF.

OpenOffice.org s'en sert dans les champs autorise par le norme specifique a l'application du nom de OpenOffice.org. Koffice, Lotus etc peuvent tout a fait avoir des champs du meme acabit. Il est utilise comme tu le fais pour decredibiliser le format ODF en pretendant qu'il n'est pas defini ce qui est faux car il est totalement defini dans la doc de l'application l'utilisant et donc si tu veux mimer le meme comportement pour ta propre petite application, tu vas voir dans la doc de l'application que tu veux imiter.

Pour revenir a l'element word97 truc de microsoft oxml, lui est defini dans la norme ECMA du coup en effet sa definition complete et totale devrait etre dans le norme ce qui n'est pas le cas. Comme c'est aussi un truc d'application specifique il est optionnel et pourrait etre dans la doc de l'application en question mais comme celle ci n'existe nulle part...

Donc la j'espere que tu auras compris maintenant qu'il est absolument normal que l'element en question ne soit pas defini dans la norme ODF car il n'existe pas dans la norme. Il existe uniquement dans les champs specifique a l'application OpenOffice.org et defini dans la doc de ce dernier.

Bon score inchange ODF 1 - microsoft oxml 0

et? Le jour ou SUN arrete de participer a la defintion de la norme ODF au sein de OASIS. SUN ne pourra pas sortir un truc s'appelant ODF.
Microsoft par contre peut tout a fait decider demain que microsoft oxml est en version 2 et revenir sur ses brevets. Mais bon c'est vrai Microsoft est une gentille entreprise qui entretient une compatibilite parfaite entre ses versions de format de document de tel sorte a ne pas forcer ses vaches a lait euh clients a upgrader...

porte plainte a l'europe et apres on verra :)

non non il ne fait pas parti de la spec ISO ou tu l'as mal orthographie.
Fait donc la recherche dans le documet decrivant ODF 1.0 et cela n'existe pas ton: UseFormerLineSpacing.

Je t'ai deja donne la spec par contre j'atttend moi encore une fois la def de word97.

oui enfin Microsoft oxml il fait "legerement" doublon avec ODF donc c'est un peu normal que vu le role de l'ISO qui est d'eviter la redondance des normes pour rien que le format soit "legerement" remis en question...

Pour les formules je prefere pas de formules que des formules fausses mais bon ca doit etre ma formation scientifique...