Microsoft / Monopole - Page 5

parce que ce ne sont pas forcément de bêtes *options* : ça peut très bien être un choix architectural divergent, qui fait qu'un super-format capable de représenter les deux formats serait horriblement compliqué -- et certainement pas "propre" (je ne connais pas du tout les détails de ODF ou de OOXML, donc je n'ai pas d'exemple concret à donner, mais il y en a forcément)

Mais pourquoi vouloir ça ? Entre MS Word 2 et 6, aucune compatibilité n'a été assurée entre les deux formats, idem entre 6 et 95... c'est uniquement depuis 95/97/2000/XP/2003 qu'il y a rétro compatibilité totale... Et ça a permit (en particulier) de s'affranchir du système de gestion des tableaux archi buggé de Word 2, par exemple.
Et sous Access, il n'y a absolument aucune rétro compatibilité assurée entre les différentes versions.

Pollux (./119) :
oui enfin c'est pas juste une question de rajouter qques options, il y a forcément des façons de représenter certaines choses qui sont assez incompatibles entre ODF et .doc, donc il y a deux solutions : casser légèrement les données (c'est ce que fait par exemple openoffice quand il ouvre un .doc) -- mais qqun qui achèterait le dernier word et qui verrait la mise en page de tous ses documents complètement cassée aurait des raisons d'être mécontent ;

Pollux (./121) :
parce que ce ne sont pas forcément de bêtes *options* : ça peut très bien être un choix architectural divergent, qui fait qu'un super-format capable de représenter les deux formats serait horriblement compliqué -- et certainement pas "propre" (je ne connais pas du tout les détails de ODF ou de OOXML, donc je n'ai pas d'exemple concret à donner, mais il y en a forcément)

Pourquoi ? Un convertisseur doit être possible ou le format utilisé est incomplet.

ça veut dire quoi incomplet ? il n'y a pas de convertisseur sans dégradation de TrueType vers Type1 (parce que les polices TrueType contiennent des instructions en bytecode pour le rasterizer, qui ne sont pas traductibles en Type1), et encore moins en sens inverse (parce que le Type1 utilise des courbes de Bézier cubiques et le TrueType des quadratiques), mais aucun des formats n'est « incomplet », si ?

c'est pour ça que le « super-format [OpenType] capable de représenter les deux formats » est en fait en gros un wrapper (du coup je sais pas si c'est « horriblement compliqué », mais d'un certain point de vue c'est clairement pas très « propre » ^^)

Sally (./124) :
ça veut dire quoi incomplet ?

Qui n'est pas complet.

Sally (./124) :
mais aucun des formats n'est « incomplet », si ?

Puisque tu me fais comprendre qu'on ne peut pas réprésenter n'importe quelle police sans pertes, oui.
Est-ce génant ? Je ne pense pas. Il est tout à fait concevable que par compatibilité, les polices soient inclues dans le format.

Nil (./122) :
Mais pourquoi vouloir ça ? Entre MS Word 2 et 6, aucune compatibilité n'a été assurée entre les deux formats, idem entre 6 et 95... c'est uniquement depuis 95/97/2000/XP/2003 qu'il y a rétro compatibilité totale... Et ça a permit (en particulier) de s'affranchir du système de gestion des tableaux archi buggé de Word 2, par exemple.

oui mais word est devenu tellement ubiquiteux comme format d'échange qu'ils n'ont vraiment pas intérêt à changer... un type qui s'achète un nouveau portable avec le dernier office préinstallé serait franchement dégoûté s'il était incapable de travailler avec d'autres sur des documents sans niquer la mise en forme à chaque fois ^^
et puis peut-être qu'à l'époque de word2 ils avaient de bonnes raisons de changer parce que c'était mal foutu, mais maintenant word97 répond à peu près aux besoins des gens...

Sally (./124) :
c'est pour ça que le « super-format [OpenType] capable de représenter les deux formats » est en fait en gros un wrapper (du coup je sais pas si c'est « horriblement compliqué », mais d'un certain point de vue c'est clairement pas très « propre » ^^)

oui, mais un wrapper ne convient pas pour un traitement de texte, pour la simple raison que contrairement à une font qui est un gros bloc de données non éditable par l'utilisateur, on peut faire des copier-coller d'un bout de document dans un autre : je te souhaite bon courage pour mélanger les arbres de formats incompatibles, tout en gardant les styles et compagnie en commun pour éviter de dupliquer toute l'interface avec une boîte de dialogue "styles odt" et une boîte de dialogue "styles ooxml" bref ce serait clairement bcp plus compliqué que la somme word+openoffice si on voulait une compatibilité parfaite...

Pollux (./126) :
ubiquiteux

ubiquiste tu veux dire ? moi je dis « ubique » c'est plus joli mais... oh ! ubique est attesté dans le dictionnaire (dans le TLFi à tout le moins), on m'a menti (enfin normalement on dit ubiquiste, il paraît)

ah tiens je savais pas que ça existait (par contre je savais que tu ferais une remarque sur ce mot )

(Pfff, si on n'est pas abonné à Mouton, on ne comprend rien à la moitié des conversations ici)

(hmm, c'est pas le contraire?)

Bon alors ce n'est donc pas un mot inventé par P.K.Dick?

Pollux (./126) :
maintenant word97 répond à peu près aux besoins des gens...

c'est vrai.., maintenant que j'y pense, windows 98 répond aussi à peu près aux besoins des gens.

(Qu'est-ce que tu ne comprends pas ?)
Hippo > il a été utilisé par Valéry en 1930 (si tu parles d'ubique)
sinon ubiquiste est attesté au XVIe siècle, et au XVIIIe dans le sens moderne.
Il existe même un verbe ubiquiter si tu veux
(Et P. K. Dick écrit en français ?)

pedrolane (./131) :

Pollux (./126) :
maintenant word97 répond à peu près aux besoins des gens...

c'est vrai.., maintenant que j'y pense, windows 98 répond aussi à peu près aux besoins des gens.

je parle du format, qui est plutôt bien adapté à la (grosse) niche qu'il occupe... "" (et non, windows 98 ne répond pas bien aux besoins des gens : il n'est pas stable parce qu'il n'isole pas les processus, par exemple ; maintenant à toi de me trouver un problème dans le format word97 qui 1] nécessiterait un changement significatif du format, pas une simple extension, et 2] ne serait pas du bloat inadapté à l'usage que les gens font d'un traitement de texte)

ben le roman est en anglais, mais même dans la version anglais, il y a un "elixir of ubique", variante de l'"ubik", qui fait très archaïque et peut être français (ou tout simplement latin?).

ubique est un mot latin oui (mais c'est un adverbe : « partout »)
ubiquité et ubiquiste sont des constructions savantes à partir de ce mot latin.
je n'ai pas d'indication d'étymologie sur l'adjectif ubique en français, mais a priori c'est une rétro-construction à partir d'« ubiquité » ^^ (enfin quand moi je l'ai inventé c'était ça, mais je sais pas si Valéry a fait pareil que moi ). Enfin ça m'étonnerait que ça soit piqué directement du latin, ça serait vraiment très artificiel... ubiquiste est clairement plus logique étymologiquement, mais tellement moins drôle

Kevin Kofler (./114) :

Lionel Debroux (./113) :
* envoi par un membre de Microsoft d'incitations à voter "oui" en Suède (=> vote invalidé);

Et => position de la Suède inversée "oui"->"non".

C'était pas "abstention" plutôt ?

Pollux (./133) :
maintenant à toi de me trouver un problème dans le format word97 qui 1] nécessiterait un changement significatif du format, pas une simple extension, et 2] ne serait pas du bloat inadapté à l'usage que les gens font d'un traitement de texte)

Le problème, c'est que le format n'est pas le standard ISO, qui est l'ODF!
Mais bien sûr le monopole a préféré redéfinir l'obscurité^H^H^H^H^H^H^H^H^H^H^Hl'Office "Open" XML (qui n'est qu'un mapping XML du vieux format binaire avec toutes ses bizarreries, c'est pour ça que c'est aussi lié aux applications et au système d'exploitation qui l'implémentent et qu'il y a tellement de constantes numériques en le format non-standard de ce système d'exploitation monopoliste là où ils devraient utiliser des identifiants alphanumériques ISO) comme le nouveau standard au lieu de changer l'ampoule^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hpasser à l'ODF.

Quelques infos techniques sur OOXML:
http://www.robweir.com/blog/2007/07/formula-for-failure.html (unités des arguments des fonctions non définies; formules _fausses_; localisation à chier). Résumé à la fin:
|cite]As I've shown, in the rush to write a 6,000 page standard in less than a year, Ecma dropped the ball. OOXML's spreadsheet formula is worse than missing. It has incorrect formulas that, if implemented according to this standard, would raise important health, safety and environmental concerns, aside from the obvious financial risks of a spreadsheet that calculates incorrect results. This standard is seriously messed up. Shame on all those who praised and continue to praise the OOXML formula specification without actually reading it.[/cite]
(oui, risques financiers, puisque Sarbanes-Oxley rend responsables les CEO qui signent des données financières fausses)


http://holloway.co.nz/can-other-vendors-implement-ooxml.html (non, clairement pas, avec de nombreuses choses non définies dans le standard, que seul Office pourra implémenter pleinement en pratique... ça prendrait des milliers d'hommes-années aux autres vendeurs pour arriver à une interopérabilité "parfaite", que Microsoft pourrait de toute façon casser à peu près quand ça les chante - il suffit de changer de version, comme entre Word 2 et Word 6, puis entre à peu près toutes les versions suivantes).


Et je n'arrive pas à retrouver une page où quelqu'un décrit quelques conneries qu'on peut faire en manipulant le XML à la main, en exploitant les imprécisions du standard...

Et en exploitant surtout que Excel utilise aussi un fichier binaire non spécifié qui accompagne le XML dans le même ZIP (soi-disant "pour des raisons de performances") et que toucher au XML casse le contenu de ce fichier binaire.

super

Kevin Kofler (./139) :
Et en exploitant surtout que Excel utilise aussi un fichier binaire non spécifié qui accompagne le XML dans le même ZIP (soi-disant "pour des raisons de performances") et que toucher au XML casse le contenu de ce fichier binaire.

C'est une Requested Feature ça...

Non, c'est l'habituel mensonge du monopole, ils prétendent utiliser de l'XML alors qu'en réalité ils utilisent un mélange XML-binaire.

ils n'ont pas dit le contraire, "j'utilise une brosse à dent" n'induit pas que je n'utilise pas de peigne...

utiliser exclusivement XML est une Requested Feature

Il contient quoi le fichier binaire ? (parceque je viens d'ouvrir quelques documents sur lesquels j'ai travaillé, et ils ne contiennent que des fichiers .xml, en-dehors des images incluses)

Bon, j'ai relu les documents et en fait les .bin pour des raisons de performance dans Excel sont optionnels (mais ça ne veut pas dire que personne ne créera des .xlsb que personne ne peut lire avec des outils ne provenant pas du monopole). En revanche, il y a des .bin qui sont toujours stockés sous forme binaire non documentée, par exemple le code VBA.

Référence: http://www.codeproject.com/cs/library/office2007bin.asp

effectivement, je n'avais jamais remarqué mais ça a l'air d'être deux choses bien distinctes, donc tant qu'on utilise le format de sauvegarde par défaut, les données (autre que macros VBA) sont bien en XML, et il est possible de les modifier.

Kevin Kofler (./142) :
Non, c'est l'habituel mensonge du monopole, ils prétendent utiliser de l'XML alors qu'en réalité ils utilisent un mélange XML-binaire.

je crois qu'il va falloir revoir ta définition du monopole

Tu veux que je les appelle comment alors? Money Sharks?

J'y peux rien si c'est pas la définition que tu voudrais

(ouhla ça poste dans tous les sens, je repars de loin)

Ce n'est pas pour argumenter (je ne connais pas suffisamment .NET), juste pour que ce soit plus précis :

Zephyr (./24) :
- Plus grande cohérence au niveau des types (pas de types int / float & co qui sont non-objets et s'opposent donc à tous les autres)

Avec l'auto-boxing de Java 5 plus de problèmes (à part pour les passages par référence comme tu notes).

- Introduction de pas mal de mots-clés très agréables pour alléger l'écriture du code (foreach, is/as, etc)

Java 5 a ses boucles améliorées. instanceof est l'équivalent de is, mais il n'y a pas de as (est-ce vraiment utile ?)

- Concept de pointeurs sur fonction/méthode templatée ou non extrêmement puissant via les "delegate"
- Passage des variables par valeur ou référence au choix (et non pas "par valeur pour les int/float, par référence pour les objets")
- Vrai support des templates présent dès le début et pas ajouté à l'arrache => API correctement templatée
- Déclarations anonymes de fonctions avec accès au scope appelant, pour effectuer des recherches dans une collection selon plusieurs critères en 2 ou 3 lignes seulement par exemple
- Surcharge/redéfinition des opérateurs
- Gestion des évènements réduite à sa plus simple expression (mot clé "event")

Tout ça est pris en charge directement par Groovy, lorsque l'on souhaite troquer Java pour des facilités syntaxiques. Groovy n'est pas une bizarrerie, il deviendra très probablement prochainement un langage standard alternatif (il est déjà standardisé), et au moins un des pilier techniques. Il propose une compatibilité complète et bidirectionnel avec Java (le "vrai"). Je code au moins 1.5 fois plus vite avec et en 2 fois moins de place.