Journal Microsoft office 2007 ne sait pas lire Microsoft openXML...

Posté par .
Tags : aucun
0
7
août
2007
et oui c'est tellement facile a implementer les 6000 pages du format "ouvert" de microsoft que meme eux ont ete incapable de le faire pour la version Office 2007 pour Mac et qu'il y a meme tres peu de chance que la version Office 2008 l'ait a son lancement... Si j'etais mauvaise langue je pourrai suggerer que cela est du a l'utilisation intensive des parti non documente et totalement lie aux API MS Windows mais c'est pas mon style donc je ne le dis pas :)

C'est encore pire que ce que je croyais ce format... Il n'existe que dans une seule suite office et une seule plate-forme. Le meme vendeur et createur etant incapable de l'implementer correctement ailleurs... Cela laisse reveur sur la possibilite de reussite pour une suite office non Microsoft Windows.

http://www.infoworld.com/article/07/08/02/Microsoft-delays-M(...)

ah petite remarque il existe un converteur docx -> rtf ... Sachant comment le rtf est "normalise" ca doit etre rigolo les conversions...
  • # Toujours aussi intelligent

    Posté par . Évalué à -10.

    T'as vu ou que le delai etait du a l'implementation d'OpenXML dans le soft ?

    Ah oui nulle part.

    Vraiment, une greffe de cerveau te serait extremement utile. (une insulte la ? Ben oui, mais vu ta mauvaise foi puante tu la merite bien).
    • [^] # Re: Toujours aussi intelligent

      Posté par (page perso) . Évalué à 10.

      Eisler, who just came on board Microsoft's Mac Business Unit in June, did not give an explanation for the schedule slip. 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.


      Nan, vraiment, arrête de venir ici déverser des flots de mauvaise foi. Code, plutôt, comme ça ça sortira plus vite :)
  • # Paille, poutre, etc.

    Posté par . Évalué à 10.

    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)
    • [^] # Re: Paille, poutre, etc.

      Posté par . Évalué à 1.

      Le pire, c'est lorsque OpenOffice n'ouvre pas correctement un document rédigé avec une version antérieure (et que ce document est rédigé par M. Rocard) :

      http://linuxfr.org/comments/818902.html#818902
      • [^] # Re: Paille, poutre, etc.

        Posté par . Évalué à 3.

        Heu...
        Tu peux me dire où est le problème ? Je viens d'ouvrir le document avec OpenOffice 2.2.1 et ça passe nickel (il me manque juste la police utilisée)
    • [^] # Re: Paille, poutre, etc.

      Posté par . Évalué à 7.

      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.
      Je suis perplexe.
      Tu as un exemple là ? Parce que j'ai jamais vu OpenOffice générer un fichier ODT avec des styles dans content.xml sauf les styles automatiques, qui n'ont, ça tombe bien, rien à faire dans le fichier styles.xml.

      Quant à l'interopérabilité KWord/OpenOffice, c'est surtout que tu compares avec KWord 1.6... qui a des gros gros défauts, l'implémentation est loin d'être complète. Pour KWord 2, ça s'améliore mais y'a du boulot et on manque de bras...
      • [^] # Re: Paille, poutre, etc.

        Posté par . Évalué à 2.

        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.
    • [^] # Re: Paille, poutre, etc.

      Posté par . Évalué à 3.

      je pense que la reponse a cela a ete faite de facon bien mieux que je ne le ferais jamais mais bon juste pour mes 2 cents. Je n'ai jamais considere koffice 1.x comme etant une version fini d'une suite office. Elle a toujours eu des instabilite (chez moi) et etait, niveau fonctionnalite, limitee.

      La gestion des ODF a toujours ete basique et cela fait longtemps en realite que c'est bien precise qu'elle ne sera correcte que dans koffice 2.

      Pour en revenir au sujet du journal, le probleme ne se situe pas dans 2 suites offices differentes mais la meme suite office, la meme version et faite par le meme editeur qui plus est createur du format... 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.
      • [^] # Re: Paille, poutre, etc.

        Posté par . Évalué à 2.

        -------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---------
        • [^] # Re: Paille, poutre, etc.

          Posté par . Évalué à 4.

          pour le 1) cela n'a RIEN avoir avec le format ODF mais avec les elements inclus dedans. C'est comme si tu ecris un document en chinois et que tu n'inclus pas la police dans le document (ce qui est generalement le cas) et que tu ne l'as pas sur ton systeme. La facon dont presente le ODF, dans OOo, le cadre incluant l'objet multimedia ou image est la meme quelque soit la plateforme, meme positionnement, meme taille, ce qui differencie c'est l'affichage de l'element et cela n'a, encore une fois, strictement rien avoir avec le format du document. Il existe exactement le meme probleme avec les pdf incluant des animations videos.

          Enfin petite remarque sans les brevets sur les quicktimes et la gestion bizarre des fichiers Tiff par les macs le probleme n'existerait peut etre pas aussi.

          Ceci n'a donc strictement rien avoir avec le fait que les logiciels Microsoft office sont incapable de re-ouvrir une equation si il y a changement de plateforme dans le cadre des versions <12 au minimum. La on ne parle pas de l'inclusion d'un fichier externe dans un format particulier dans le document mais carrement de la facon dont Microsoft Office gere son propre format ie mal voir pas du tout...

          Et par rapport au sujet du journal on parle d'un format de document complet d'une meme generation de suite que l'on ne peut pas ouvrir sur une des deux seules plateformes supportes et pas d'un element particulier.
  • # Aujourd'hui il y a une 2e plateforme pour OOXML

    Posté par . Évalué à 4.

    Je viens de voir que la nouvelle version de la suite d'Apple, iWork '08, supporte le OOXML en lecture :
    http://www.apple.com/fr/iwork/pages/#compatible
    (là c'est juste pour le traitement de texte, mais c'est pareil pour le tableur et le "présenteur")
    Bon, Apple n'étant pas toujours connu pour son ouverture à ce niveau (son format de fichier maison est à moitié proprio / à moitié ouvert mais à chier), ça ne m'étonne pas, mais je trouve ça dommage que OOXML commence à si "facilement" se diffuser : je pensais qu'un "opposant" comme Apple aurait plutôt rechigné à implémenter ce format. D'un côté, niveau suite bureautique, ils n'essayent pas vraiment de se battre puisque MS Office est le dernier logiciel encore porté aujourd'hui sur Mac, et il ne risque pas de s'éteindre à mon avis.
    Enfin bon, comme c'est qu'en lecture, ils n'ont dû avoir qu'à modifier leur parser (les précédentes versions de iWork lisaient déjà les anciens format de MSO) étant donné la ressemblance troublante entre OOXML et ses prédécesseurs...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.