Publication du Linbox-Converter, logiciel libre de conversion de documents MS-Office.

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
18
oct.
2004
Communauté
L'Adullact et la société Linbox/Free&ALter Soft viennent d'annoncer la publication du logiciel Linbox Converter.

Linbox-Converter est un logiciel libre de conversion de documents MS-Office (Word, Excel, Powerpoint) vers les formats PDF, PostScript, texte, HTML, RTF, et TIFF.

Il est publié sous licence GPL sur le site collaboratif de l'Adullact.

Linbox-Converter est une application de type client/serveur écrite en langage Python. Le client transmet au serveur les documents MS-Office à convertir. Le serveur les transforme alors dans le format demandé (PDF, PostScript, HTML, texte, RTF, ou TIFF), puis renvoie le résultat au client.

Il permet d'effectuer des traitements automatiques sur des fichiers MS-Office tels que leur conversion automatique en PDF pour publication sur Intranet/Internet ou pour archivage dans un format ouvert pérenne.

Un fichier PDF résultant d'une conversion représente exactement la sortie imprimée par MS-Office. De plus, le PDF peut être imprimé sur le client et le résultat sera exactement le même qu'une impression directe à partir de MS-Office sous MS-Windows.

Aller plus loin

  • # ça, c'est une très bonne nouvelle !

    Posté par  . Évalué à 6.

    Passer dans un format ouvert (surtout compréhensible) est le principal frein au migration en règle générale. Qu'un outils le fasse de manière automatiser va envlever cet obstacle !

    Vive l'interaction, vive la résistance !

    Ps: il ne manque plus qu'un filtre vers OO !

    • [^] # Re: ça, c'est une très bonne nouvelle !

      Posté par  . Évalué à 10.

      Par contre je note que le serveur tourne sous Windows et qu'il faut MS Office, donc pas de miracle. C'est, je simplifie mais pas pour dénigrer leur travail, l'utilisation du module DCom de Python pour piloter Word ou Excel depuis un script et commander l'impression. Les différents formats de sortie doivent être tirés de sorties d'imprimantes virtuelles, de « Enregistrer sous » depuis l'application et de tidy pour la sortie HTML.

      Mais ça n'enlève rien à leur travail, au contraire. Même si vous savez faire chaque chose individuellement, combien de mois auriez-vous passé à écrire un logiciel équivalent ?

      > Ps: il ne manque plus qu'un filtre vers OO !

      Oui on pouvait rêver à ça en lisant le titre mais leur logiciel n'a même pas à connaître les formats fermés de MS Office.

      P.S. Il existe plein de logiciels pour en faire autant depuis Linux avec des logiciels libres mais avec évidemment des résultats moins bons.

      • [^] # Re: ça, c'est une très bonne nouvelle !

        Posté par  . Évalué à 2.

        C'est au contraire un prérequis que d'utiliser Word si on désire avoir une reprise du document qui soit la plus fidèle possible à l'original (je dis bien la plus fidèle possible, parce que si ca vient de Office 97 comme souvent, on voit les limites en terme de compatibilité entre outils d'un même éditeur ... pom pom)

        Donc oui, utilisation du logiciel propriétaire initial, mais pour une bonne cause.
        Et quelque part utiliser Word pour s'en libérer, c'est un pied de nez qui me plait assez :)

        M

        • [^] # Re: ça, c'est une très bonne nouvelle !

          Posté par  (site web personnel) . Évalué à 2.

          Le document pdf est un document final, destiné à être vu, imprimé et archivé. Ce n'est pas la vocation du .doc qui ne sert qu'à stocker son brouillon.

          Dans le cas d'une stratégie de migration, Linbox-Converter permet de garantir la pérennité des documents électroniques réalisés avec Word. C'est très important.

          Quelques exemples :
          Il y a quelques jours, j'ai monté un nouvel ordinateur pour l'une de mes filles (celle de St Émilion). C'est la première des trois à ne plus avoir de double boot. Mais avant de transférer ses données, il a fallu que je transforme les fichiers Word2 en Word95 (ou Word97) afin qu'ils soient encore lisibles par les traitements de textes actuels.
          J'ai chez moi de vieux fichiers Word 5 que je ne sais plus ouvrir qu'avec vim...

          • [^] # Re: ça, c'est une très bonne nouvelle !

            Posté par  . Évalué à 4.

            > Le document pdf est un document final, destiné à être vu, imprimé et archivé.

            Il serait bien de pouvoir ouvrir un fichier PDF dans OOo et de conserver le maximum de mise en page.

            • [^] # Re: ça, c'est une très bonne nouvelle !

              Posté par  (site web personnel) . Évalué à 2.

              Il faut ouvrir le pdf avec kwriter. Après on peut le travailler et éventuelement le passer à oowriter
              Attention : dans un pdf, il n'est question que de positionnement, il n'y a aucune notion de style. Il est donc difficile de le reconstituer.

      • [^] # Re: ça, c'est une très bonne nouvelle !

        Posté par  . Évalué à 1.

        Par contre je note que le serveur tourne sous Windows et qu'il faut MS Office, donc pas de miracle.

        Dans ce cas l'utilisation de PDFCreator n'est-elle pas plus simple ?

    • [^] # Re: ça, c'est une très bonne nouvelle !

      Posté par  . Évalué à 2.

      Je pensais que le principal obstacle à la migration était les macros MS Office. Toujours rien de ce coté la.

    • [^] # Re: ça, c'est une très bonne nouvelle !

      Posté par  . Évalué à 1.

      en fait il y a déjà un converteur programmé en OOoBasic qui permet de passer de tous les formats d'entrée de OOo dans tous les formats de sortie de OOo. Evidemment, on souffre des limitations d'import et d'export dans ces différents formats. Il permet de sélectionner un répertoire avec tous les fichiers à convertir, on peut donc faire du travail de masse. Et il est facile à modifier.

  • # Et pourquoi pas un export OOo ?

    Posté par  . Évalué à 6.

    Ce projet est tout de même très sympathique. Trouver des applications "équivalentes" est une chose, mais une grosse partie de la complexité (et du coût !) d'une migration vient de la migration des données "visibles" (documents) et "invisibles" (dictionnaires personnalisés, raccourcis et de manière générale la "configuration" personnelle des utilisateurs). Des logiciels comme Linbox-Converter offrent la possibilité d'industrialiser les processus de migration et enlèvent un frein majeur à l'adoption des solutions libres.

    Dans le même genre, ServOO est un module pour CMS qui permet de "traduire" un document MS Word ou OOWriter en document propre à un CMS. Il a été développé pour le CMS d'édition électronique Lodel mais il se peut que dans un avenir proche il devienne un projet indépendant utilisable par tous les CMS.

    http://www.lodel.org/servoo.php(...)

    L'intérêt ? Les rédacteurs peuvent continuer à utiliser leur outil favori pour rédiger et styler leurs articles. Accessoirement, on peut imaginer une migration complète d'un environnement avec clients lourds (MS-Office, OOO, etc.) à un système partagé de gestion de documents électroniques.

    Quand je vois tout ce qu'on peut faire avec les interfaces web (quite à utiliser des composants "pas encore standard" comme HTMLArea http://www.interactivetools.com/products/htmlarea/(...) , propres à un navigateur (XUL, ActiveX) ou au pire des applets Java ou Flash), je me met à rêver d'une bureautique distribuée totalement libérée des applications lourdes.

    BeOS le faisait il y a 20 ans !

  • # PS to PDF

    Posté par  . Évalué à 3.

    Je viens de demander ceci à linbox :

    Je note que le protocole utilisé (PS -> PDF)
    empêche la conservation des hyperliens de type HTTP,
    FTP, mailto, etc.
    de sorte qu'un lien word http://www.linbox.com(...)
    transformé automatiquement par word en hyperlien,
    ne sera plus cliquable dans sa version PDF.

    Avez-vous en vue une solution à cette difficulté ?

  • # Intégration du point de vus utilisateur final ?

    Posté par  . Évalué à 1.

    L'astuce en Python est jolie, et cela permet de se limiter à une seule licence de Office par entreprise (C'est pas parfait, mais tout de même fort appréciable), mais l'interret de la chose dépend fortement du type de client que l'on propose...

    Si le client est un script python en ligne de commande, alors c'est sans aucun interet, il coutera moins cher de payer des licences que de former les utilisateur...

    En revanche, si le client est :
    - Un filtre sur le serveur mail (qui ajouterais automatiquement la version pdf d'une piece jointe en .doc)
    - Un plug'in mozilla/firefox avec un "telecharger en pdf" dans le menu contextuel
    - une config qui associe les .doc au script ligne de commande + lancement de Xpdf (dans gnome ou kde)
    - avez-vous d'autre idée ?

    Alors cela peut-être une formidable avancé (en attendant l'intégration à OOo ;-))

    • [^] # Re: Intégration du point de vus utilisateur final ?

      Posté par  . Évalué à 1.

      - avez-vous d'autres idées ?

      Avec Zope on pourrait faire une petite appli web de conversion de documents.

    • [^] # Re: Intégration du point de vus utilisateur final ?

      Posté par  . Évalué à 1.

      > Si le client est un script python en ligne de commande, alors c'est sans aucun interet...

      Au contraire si c'est en ligne de commande ca me semble plus souple et on peut surement y ajouter toute sorte d'interfaces graphiques permettant de faire ce que l'on veut.

      > - une config qui associe les .doc au script ligne de commande + lancement de Xpdf (dans gnome ou kde)

      Lu sur le site:
      "Le programme est disponible en version:
      * ligne de commandes permettant de lancer des conversions en batche ;
      * intégrée à Mozilla/Netscape permettant, par exemple, l'affichage du PDF directement dans le plugin Acrobat Reader du navigateur.
      "

      Pour le reste comme c'est en GPL et sur un gforge j'imagine qu'il y a moyen de suggerer des trucs ou de fournir des contribs...

  • # Vitesse export PDF ?

    Posté par  . Évalué à 2.

    Bravo pour l'initiative ! (en fait ça fait longtemps que j'en rêvais et ils l'ont fait !)

    Par contre, malgré tous ses défauts, M$-Office a au moins l'avantage de s'ouvrir très vite, à comparer avec la lourdeur de Ooo (même avec le pré-chargement). Cela suffit à décourager des utilisateurs potentiels d'Ooo.

    Du coup, je m'interroge sur la réactivité / utilisabilité de cette solution pour les utilisateurs "non convaincus" à la base : pour utiliser (quotidiennement) PDFcreator (qui utilise ghostscript) pour passer du .doc en PDF je peux dire que malgré tous ses atouts la vitesse n'est pas son point fort (encore pire qu'une ouverture avec Ooo) => si on rajoute une couche serveur / réseau en Python qu'est-ce que ça doit être... ! (des retours sur ce point ?)

    J'imagine aussi que l'export en RTF est plus véloce mais du coup la mise en page peut être en partie perdue non ?

Suivre le flux des commentaires

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