ODTPHP, l'API PHP pour manipuler des fichiers OpenOffice en version 1.0

Posté par (page perso) . Modéré par patrick_g.
Tags :
10
7
juil.
2009
PHP
À l'occasion des PHPDays, Anaska, le pôle formation d'Alter Way, annonce la disponibilité de la version OdtPHP 1.0, l'API PHP pour OpenOffice qui permet de manipuler des fichiers au format OpenDocument.

Distribué sous la licence GPL, OdtPHP permet de générer automatiquement des documents OpenOffice à partir de modèles. Les utilisateurs ont ainsi la capacité de s'en servir directement au sein de leurs applications PHP (sans nécessiter OpenOffice). Les fonctionnalités d'OdtPHP sont multiples :
  • Substitution des balises du modèle OpenOffice par du contenu texte ou des images ;
  • Multiplication des lignes de tableaux OpenOffice ;
  • Export du résultat final sur un fichier du serveur ou directement vers le navigateur du client ;
  • Imbrication et répétition de boucles ;
  • .../...

"OdtPHP est une API PHP pour OpenOffice qui permet d'exploiter au maximum le format XML des fichiers au format OpenDocument. Avec odtPHP la communauté du libre s'organise encore un peu plus pour offrir une réponse globale aux demandes des utilisateurs et de l'industrie."
Cyril PIERRE de GEYER

OdtPHP est développé par une équipe d'experts PHP : Cyril PIERRE DE GEYER, co-fondateur de l'AFUP et directeur général de Anaska Alter Way Formation, Julien PAULI, architecte logiciel expert certifié PHP, ZendFramework et formateur chez Anaska Alter Way Formation, Olivier BOOKLAGE, chargé d'affaires chez MVF et Vincent BROUTÉ, responsable du site DepanneTonPC, certifié Zend PHP 5.

Pour télécharger la version 1.0 d'odt PHP : http://www.odtphp.com/

P.S. : merci aux auteurs de commentaires lors de l'annonce de la 0.9 qui ont permis d'améliorer l'API.
  • # Le rapport avec OpenOffice ?

    Posté par . Évalué à 10.

    Bonne news et bonne nouvelle.

    Mais quel rapport avec OpenOffice (cité 7 fois dans la news) ?

    La bibliothèque permet de pondre des documents au format OpenDocument (comme précisé).

    OpenOffice, comme d'autres logiciels, et comme cette bibliothèque, sait aussi le faire, c'est vrai.

    Mais il ne faut pas mélanger le logiciel et le format (et entretenir l'amalgame dans la tête des gens).
    • [^] # Re: Le rapport avec OpenOffice ?

      Posté par . Évalué à 2.

      Quels logiciels permettent d'exploiter ce format ?
      • [^] # Re: Le rapport avec OpenOffice ?

        Posté par . Évalué à 7.

        openoffice, kwrite, word (mouhaha, en théorie), abiword
        • [^] # Re: Le rapport avec OpenOffice ?

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

          Avec kwrite, ce sera sport... c'est plutôt koffice!

          ⚓ À g'Auch TOUTE! http://agauch.online.fr

        • [^] # Re: Le rapport avec OpenOffice ?

          Posté par . Évalué à 3.

          C'est vrai, c'est drole.

          Ce qui est moins drole: http://www.adjb.net/post/Notes-on-Document-Conformance-and-P(...)

          On scrolle vers le bas, pour voir le test de conformance sur les documents donnes par Rob Weir :

          Ceux qui sont conforme au standard : KSpread, MS Office et le plugin Clever Age

          Ceux qui ne sont pas conforme : Google, IBM Symphony, OpenOffice

          Drole hein ?
          • [^] # Re: Le rapport avec OpenOffice ?

            Posté par . Évalué à 2.

            Update: I have now been pointed at the draft of Part 3 of ODF 1.2, and it does indeed contain a new schema. This draft is unfinished and contains non conformance clause, so it is not really possible to know for sure whether a package conforms to it. However, the OOo package here is invalid to the schema. I am going to assume that Part 3 will mirror the draft of Part 1 of ODF 1.2, and so will require schema validity. On that (reasonable) basis this OOo package is non-conformant; but of course the draft might change tomorrow. We do not know quite what version of the spec is being targetted here ...

            OOo 3 ne vise pas odf 1.1, pour ça c'est OOo 2.4

            Pour prendre une citation de Steve Ballmer fort à propos[1] :

            « So, Yes: we gonna embrace those standards, but we're also gonna do innovative things of our own just as we know many other actors in the market will also do innovative things of their own. »

            [1] http://formats-ouverts.org/blog/2006/05/22/814-une-declarati(...)
            • [^] # Re: Le rapport avec OpenOffice ?

              Posté par . Évalué à 2.

              Tout a fait, OOo 3 vise un format (ODF 1.2) qui n'est pas encore fini et qui change encore, ce qui est vraiment super d'un point de vue interop...
              • [^] # Re: Le rapport avec OpenOffice ?

                Posté par . Évalué à 1.

                Bah oui, c'est super, comme pour le CSS 2

                http://www.w3.org/TR/CSS2/
                W3C Candidate Recommendation 23 April 2009

                Grâce à Mozilla et Microsoft qui vise une norme pas encore fini et qui change encore on peut mettre en place des sites et ajuster, remonter les anomalies, et éventuellement corrigé la norme au fil de l'eau.
                [/mauvais foi]

                Développement ouvert, coopération d'entreprises (W3C), logiciel libre (ou pas), toussa...
                • [^] # Re: Le rapport avec OpenOffice ?

                  Posté par . Évalué à 2.

                  Ouais c'est super, comme ca ton document que t'as cree il y a 6 mois, il ne pourra pas etre ouvert par un soft respectant ODF 1.2 qui sortira dans 6 mois, car la spec aura change.

                  C'est beau l'interop non ?
                  • [^] # Re: Le rapport avec OpenOffice ?

                    Posté par . Évalué à 1.

                    Au pire, j'imagine qu'il faudra ouvrir et enregistrer le document dans OOo4 quand la norme sera finalisé. Rien de bien grave.

                    Ce n'est pas ce que compte faire Microsoft lorsqu'ils respecteront ooxml avec Office 13 pour convertir les documents d'Office 2007 qui ne respectent pas la norme ?

                    Mais c'est avec plusieurs grand si :
                    - si l'implémentation de SUN n'est pas celle qui est effectivement normalisé (SUN ayant pû traité les ambiguïtés qui n'ont pas forcément été vu lors de l'élaboration du draft). Ce qui est fort probable.
                    - si le format de OOo3 n'a pas de compatibilité avec odf1.2

                    Ou pourquoi Microsoft a sorti Office 2007 avant la normalisation iso ? La citation de Ballmer ne s'applique qu'à MS ?
                    • [^] # Re: Le rapport avec OpenOffice ?

                      Posté par . Évalué à 1.

                      Au pire, j'imagine qu'il faudra ouvrir et enregistrer le document dans OOo4 quand la norme sera finalisé. Rien de bien grave.

                      Ce n'est pas ce que compte faire Microsoft lorsqu'ils respecteront ooxml avec Office 13 pour convertir les documents d'Office 2007 qui ne respectent pas la norme ?


                      C'est exactement le meme probleme oui, et tout le monde avait gueule sur MS a l'epoque, mais visiblement lorsque c'est fait par un LL cela ne semble pas etre un probleme...

                      Ou pourquoi Microsoft a sorti Office 2007 avant la normalisation iso ? La citation de Ballmer ne s'applique qu'à MS ?

                      Oh ca s'applique a MS aussi, ils se sont bien fait flame a l'epoque deja, chacun son tour.
                      • [^] # Re: Le rapport avec OpenOffice ?

                        Posté par . Évalué à 2.

                        C'est exactement le meme probleme oui, et tout le monde avait gueule sur MS a l'epoque, mais visiblement lorsque c'est fait par un LL cela ne semble pas etre un probleme...

                        Tu avais gueulé aussi ? :p

                        C'est un problème et il est relevé. Je ne recommande pas de déploiement d'OOo3 si l'archivage est important, les administrations restent sur OOo2.4, de la même façon que je ne recommande pas de déploiement d'Office 2007 et qu'il est peu déployé dans l'administration.

                        J'ai l'impression que SUN se prend des attaques excessive la dessus alors que peu de monde avait signalé ce problème pour MS. Le problème était ooxml même, plus que Office 2007 (qui a eut plus d'encensement que de critiques, il me semble, preuve s'il en est des ventes d'Office 2007 aux U.S., non? De même que OOo3 est plutôt pas mal en dehors de l'aspect archivage des documents, d'où les réductions de licences MS offices en France au moment de sa sortie, non?)


                        La citation de Ballmer ne s'applique qu'à MS ?

                        Oh ca s'applique a MS aussi,


                        Euh...
  • # Bien mais insuffisant.

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

    J’ai eu besoin de générer un classeur à multiples onglets (nombre variable) en PHP.
    La seule solution que j’ai trouvé est http://excelwriterxml.sourceforge.net/

    Il est dommage qu’une telle solution n’existe pas pour le format ODC. C’est un outil PHP très petit, à l’API très simple et bien documentée. Et comme OpenOffice 2.4 lit très bien les fichiers OOXML produits (à part dans la colonne Z…), c’est presque une solution idéale.

    Allez, un défaut tout de même : ça ne gère pas les graphiques. Néanmoins, même avec ce défaut (et le bug OpenOffice de la colonne Z), ça reste la seule solution, et vraiment utilisable.

    Yves.
    • [^] # Re: Bien mais insuffisant.

      Posté par . Évalué à 1.

      pour excel il y a aussi http://www.phpexcel.net/
    • [^] # Re: Bien mais insuffisant.

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

      Ave,

      J'ai été dans ton cas avec un besoin de générer des documents OpenDocument en PHP 5 : des tableurs et des documents textes. Cela a donné Dio : http://gitorious.org/dio/ . Il permet de générer des diagrammes. C'est encore jeune, mais ça m'a suffit ! Il n'attends que des besoins et des mains pour s'améliorer. J'aimerai ajouter une batterie de tests et passer au TDD

      Étienne.
      • [^] # Re: Bien mais insuffisant.

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

        Merci beaucoup pour ce lien. Il est certain que je vais m’intéresser de près à Dio.

        Et merci aux auteurs de OdtPHP, car bien que le monde OpenDocument soit en retard sur celui de MSOffice — ce que je voulais faire passer (maladroitement ?) dans mon message précédent —, cet outil, aussi modeste soit-il, reste une bonne initiative.
        Il est dommage de lire des commentaire comme ceux qui suivent. Vous avez eu un besoin, vous avez mis votre résultat à disposition du public, c’est bien.

        Yves.
  • # Intérêt

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

    Heureusement que c'est l'été, sinon je ne crois pas que cette news serait passée.

    Une news pour un 423 lignes de PHP, qui ont certes leur utilité, mais pas celle qu'on croit deviner en lisant l'article. Cette classe permet de faire du templating sur des fichiers ODT, mais elle ne permet absolument pas de les manipuler.

    Très franchement, être quatre sur ça, et prétendre avoir réaliser un outil révolutionnaire, c'est du foutage de gueule.

    À la rigueur, un DOM qui permet de manipuler un ODT en long en large et en travers, pourquoi pas. Mais là... C'est juste un sed en moins bien.
    • [^] # Re: Intérêt

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

      Pour tout ceux qui essayent de tester, faites attention, il y a un bogue avec certaines versions récentes de PHP qui empêche OOo d'ouvrir les fichiers Zip créés par ZipArchive : http://bugs.php.net/bug.php?id=48763
      • [^] # Re: Intérêt

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

        Pour résoudre ce problème nous avons mis en place un pattern adapter qui permet qui permet de se plugger soit sur l'extension ZIP soit sur une bibliothèque PHP de manipulation ZIP.

        Donc techniquement dans la dernière version ce bug PHP est contourné.
    • [^] # Re: Intérêt

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

      Ouai, je viens de regarder ça aussi. C'est en fait juste un moteur de template dédié à ODT, avec deux trois fonctions pour faciliter l'injection de texte et d'image, et qui sait ouvrir/enregistrer un zip...

      Dommage, ils auraient pu developper des plugins pour un moteur de template existant (au hasard, jtpl ou smarty), cela leur aurait fait un peu moins de boulot, tout en profitant des fonctionnalités de ces moteurs (parce que bon, leur langage de templating est plutôt super limité, pas de gestion de cache etc...).
    • [^] # Re: Intérêt

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

      Bonjour,

      il ne s'agit certes pas d'un événement révolutionnaire mais à ce jour il n'existe pas d'outil permettant de faire ce templating via PHP de façon satisfaisante. odtPHP répond à ce manque et c'est en toute humilité que nous avons diffusé ce projet suivant le modèle OpenSource.

      Manipuler des fichiers au format OpenDocument ne relève pas de d'un simple grep ou d'une expression régulière classique car cela implique de gérer les tableaux, les boucles, etc. Le tout dans des fichiers XML bien lourds et compliqués.

      <mode troll>
      Si tu utilises SED avec PHP via la commande exec() de PHP cela te concerne, je ne me prononcerais pas sur le niveau de sécurité de tes applications ...
      </mode troll>
      • [^] # Re: Intérêt

        Posté par . Évalué à 1.

        <mode troll>
        Si tu utilises SED avec PHP via la commande exec() de PHP cela te concerne, je ne me prononcerais pas sur le niveau de sécurité de tes applications ...
        </mode troll>


        Mouais enfin, si tu utilises PHP, t'es plus à ça près niveau sécurité...
      • [^] # Re: Intérêt

        Posté par (page perso) . Évalué à -1.

        Je ne trouve pas le templating à coup de str_replace (ou même de preg_replace) une méthode de travail satisfaisante. Certes ça peut dépanner, ça permet de faire rapidement ce qui, proprement, aurait nécessité plus de temps.

        Quand à l'humilité... ce donner de la consistance avec des certification, ce n'est pas humble.

        J'ai un peu fouillé, et très franchement, je ne vois pas ce qu'il y a de compliquer à gérer les ODT : tous les outils nécessaires sont disponibles dans PHP. Avec DOMDocument et XSLT, on peut arriver à une solution plus que satisfaisante. Et puis le XML, si c'est lourd, c'est pas compliqué.

        Merci de m'avoir énervé. Du coup, je pense que je vais continuer et écrire un outil de manipulation de ces fameux ODT. (continuer parce que du coup, j'ai écrit un outil équivalent à ce que vous avez fait pour voir combien de temps ça me prendrait)


        Tu veux qu'on parle du utf8_encode qui encode une chaîne soumise sans même vérifier l'encodage de la chaîne ? ;)

        Si tu relis bien ma remarque sur sed, tu verras bien que je n'ai pas écris que j'allais invoquer sed, mais qu'en gros, ça ne faisait rien de plus (et même moins) qu'un sed.

        Quand à un exec avec sed... très franchement... on peut facilement gérer et sécuriser un tel appel. il suffit de faire attention.
  • # mouais

    Posté par . Évalué à 1.

    c'est de la publi-information avec auto-jetage de fleurs ?
    • [^] # Re: mouais

      Posté par . Évalué à 1.

      Remarque pertinente si ça n'était pas le cas de 90 % des dépêches… une dent contre celle-ci ?

      Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

      • [^] # Re: mouais

        Posté par . Évalué à 0.

        quand l'auteur de la depeche s'auto qualifie d'expert ?

        Bref la partie publicitaire, sur leur site okay, dans la depeche....

Suivre le flux des commentaires

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