LoTemplate générateur de documents à partir d'ODT

Posté par  . Édité par Nÿco, palm123, Ysabeau 🧶, bobble bubble et patrick_g. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
42
24
mai
2023
Technologie

LoTemplate est une brique libre (api, cli, lib) sous licence AGPLv3 et destinée aux développeurs et aux développeuses cherchant à intégrer dans leur solution un générateur de documents (rapport, lettre,…). Les solutions existantes pour faire cela sont variées (wkhtmltopdf, JasperReports, BIRT…) mais toutes demandent systématiquement de créer des modèles de documents en HTML, XML ou autre.

De notre côté, nous avions un besoin précis avec une contrainte : pouvoir générer des documents DOC, PDF et ODT à partir de modèles éditables par la famille Michu (Monsieur tout le monde). Ne trouvant rien en libre, nous nous sommes retroussés les manches. Nous avons donc développé LoTemplate pour permettre de générer des PDF, DOC, DOCX ou ODT depuis des documents LibreOffice servant de modèles. L’objectif est de pouvoir intégrer LoTemplate rapidement dans un projet, c’est pourquoi, il peut être utilisé via une API, en module Python ou un CLI. Les briques techniques utilisées sont LibreOffice (en mode headless), Python et Flask pour l’API.

Logo du projet

LoTemplate va permettre de faire cela à partir d’un document LibreOffice utilisant la nomenclature LoTemplate pour les variables.

Ainsi, chaque solution intégrant LoTemplate pourra permettre à l’utilisateur lambda de partir de ses documents Office pour intégrer ses modèles dans l’application sans avoir à maîtriser des technologies spécifiques et complexes. C’est pour cela que LoTemplate offre une vraie innovation pour la gestion de modèles de documents dans les applications Web.

Schéma du fonctionnement : des données au format final en passant par le module via Docker

Les développeurs et développeuses trouveront :

LoTemplate est en production depuis un an chez nous et de nombreuses améliorations sont dans les cartons : gestion des formats ODS, XLS, gestion des structures de contrôle, etc.

N’hésitez donc pas à l’utiliser, faire vos retours et, bien sûr, contribuer.

Aller plus loin

  • # Tiens...

    Posté par  . Évalué à 5.

    …en suivant les liens BIRT, j'ai la moitié des liens qui sont cassés, je me demande ce qui se passe. Ca faisait longtemps que j'avais pas été voir ce projet, je me demande où il en est.

    Et à propos de LOTemplate, j'imagine qu'avec les extensions à venir pour sortir du tableur, il faudra faire un choix dès la conception, i.e. :

    • si je crée un modèle au format ODT, je sortirais soit du word, soit du ODT, mais pas du ODS ou du Excel
    • et à l'inverse, si je crée un modèle au format ODS, je sortirais soit du excel, soit du ODS, pas pas du ODT ou du Word

    Et dans tous les cas, je pourrais sortir du PDF. C'est bien ça ?

    • [^] # Re: Tiens...

      Posté par  . Évalué à 4. Dernière modification le 24 mai 2023 à 14:47.

      C'est exactement cela.

      La gestion des ODS est dans les cartons

  • # L'idée me fait penser à relatorio

    Posté par  . Évalué à 3.

    Sauf que relatorio ne fait que module python si je ne m'abuse ; en revanche il permet déjà de produire des fichiers ods, peut-être son code est-il intéressant à consulter pour les développeurs de LoTemplate ? Le rythme de développement de relatorio semble par ailleurs assez lent.

    https://pypi.org/project/relatorio/

    • [^] # Re: L'idée me fait penser à relatorio

      Posté par  . Évalué à 2. Dernière modification le 25 mai 2023 à 08:07.

      Merci pour le lien.

      Oui, le principe de relatorio peut sembler similaire.

      Mais je ne suis pas sûre que relatorio permette la conversion de ODT vers PDF.

      AU niveau du fonctionnement tandis que relatorio dézippe les fichiers pour modifier le xml de libreoffice, LoTemplate utilise l'api de LibreOffice donc malheureusement difficile de s'inspirer du code de relatorio.

  • # Formats morts

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Les formats doc et xls sont complètements morts depuis 2014 et ont été remplacés par les formats docx et xlsx en 2007. Est-il nécessaire d'encore en parler (à mon avis non) ? En tout cas, plus de s'en préoccuper ? À mon avis non, il ne doit plus trop y avoir de documents générés avec ces formats. Même si une de mes banques exporte toujours les relevés de compte au format xls (soupirs).

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: Formats morts

      Posté par  . Évalué à 2.

      Oui, en effet, LoTemplate utilisant LibreOffice tout les format d'export de libreoffice sont possible docx et autre

  • # Autre solution

    Posté par  . Évalué à 2.

    La solution, bien que fonctionnant, me paraît bien lourde (un docker avec LibreOffice, même en headless, aïe!). Avez-vous étudié la possibilité d'utiliser PhpWord ? Il est tout à fait possible de partir d'un ODT pour obtenir les formats souhaité, et c'est du PHP sans besoin de couches supplémentaires. Je l'ai testé il y a quelques années pour un projet professionnel et il s'est révélé très efficace. Il a deux petits frères, PhpSpreadsheet et PhpPrésentation : ils sont regroupés au sein du projet PhpOffice.

    • [^] # Re: Autre solution

      Posté par  . Évalué à 2.

      Pas sûr que tu obtiennes la même qualité de résultat. La sortie PDF de PhpWord est basé sur leur générateur html. Je me demande quelle qualité de pagination tu obtiens dans ces conditions, le respect des lignes veuves/orphelines, la qualité de la césure, la mise à jour d'un index ou d'une table des matières, etc.

      J'imagine que l'intérêt d'utiliser un moteur comme celui de LibreOffice est justement de prendre en compte tout ce qu'un logiciel de traitement de texte sait faire nativement.

      Il y a quelques années, je m'étais retrouvé à coder un truc équivalent sur du pur Windows, avec du OLEAutomation. J'avais d'ailleurs à l'époque (on parle de 1998 environ !) le même problème : Word plantait régulièrement, et pas d'autre choix que de relancer toute la machine. Quand j'avais 1000 rapports à générer, ça foutait vraiment les boules de devoir rester à surveiller le bousin. Et c'était pas du headless, donc ça tournait sur une workstation. Comme ça utilisait le presse-papiers pour gérer certaines problématiques, il était interdit de toucher au PC pendant que ça tournait. Pour marquer les endroits où le texte devait être inséré, j'utilisait la notion de bookmark/signet intégrée à Word, j'imagine que l'équivalent existe dans LO.

      • [^] # Re: Autre solution

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

        Il y a quelques années, je m'étais retrouvé à coder un truc équivalent sur du pur Windows, avec du OLEAutomation. J'avais d'ailleurs à l'époque (on parle de 1998 environ !) le même problème : Word plantait régulièrement, et pas d'autre choix que de relancer toute la machine. Quand j'avais 1000 rapports à générer, ça foutait vraiment les boules de devoir rester à surveiller le bousin.

        moui, ça a toujours été un soucis avec les produits Office : même Microsft l'admet
        https://support.microsoft.com/en-us/topic/considerations-for-server-side-automation-of-office-48bcfe93-8a89-47f1-0bce-017433ad79e2

        même avec du DCOM/DDE ou du OLEAutomation, difficile de faire du réentrant :/ J'ai vu plein de serveurs avec une petite fenêtre Word avec un fond d'écran avec une flèche indiquant de ne pas la fermer o_O et il valait mieux être en mode batch /o\ (FIFO)

        Et c'était pas du headless, donc ça tournait sur une workstation.

        Star Office (prédécesseur de OOo donc) tournait sous Linux / Solaris et avait le mode headless :-) mais bon, je n'ai vu ça mis en œuvre que vers 2003…

        • [^] # Re: Autre solution

          Posté par  . Évalué à 3.

          Pendant 2 décennies, ça aura vraiment été la différence majeure Unix / Windows. Dans Windows, l'interface graphique était indissociable du reste du système. Progressivement (sur les 5/10 dernières années je dirais, même peut-être même plus) le positionnement a changé.

          A l'inverse, ça m'a aussi posé problème sur Linux. Quand on faisait du Java, et que pour une raison ou pour une autre on avait besoin de certains packages orienté rendu graphique, on se retrouvait avec des erreurs parce que le serveur X n'était pas installé sur la machine. Sous windows, on était sûr de trouver systématiquement toute cette couche.

          • [^] # Re: Autre solution

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 28 mai 2023 à 22:57.

            A l'inverse, ça m'a aussi posé problème sur Linux
            parce que le serveur X n'était pas installé sur la machine

            hmmm problème du développeur « chez moi ça marche »
            bah j'envoie les développeurs gérer leurs livraisons en prod' et tenter de faire tourner leurs programmes (spa gagné du 1er coup :p).

            moui, sur un serveur tu installes le minimum, ça réduit la surface d'attaque.

            Ensuite, il y a un peu moins de soucis avec la QA :D
            Si j'étais reloud, je leur demanderais que ça fonctionne sur HP-UX (mort), AIX (bientôt mort), le truc de Bull (enterré).

            • [^] # Re: Autre solution

              Posté par  . Évalué à 2.

              hmmm problème du développeur « chez moi ça marche »

              Tu pense que les ingénieurs de Sun bossait sur Windows ou n'avaient pas en tête d'usages sans interface graphique ?

              Je vois pas de problème particulier à avoir des warnings surtout quand ils sont désactivables. D'ailleurs si c'était le problème du chez moi ça marche ça planterait.

              Si j'étais reloud, je leur demanderais que ça fonctionne sur HP-UX (mort), AIX (bientôt mort), le truc de Bull (enterré).

              Je ne connais pas d'unix de Bull. Ils ont contribué à AIX, mais je leur connaît pas d'autres unix. Ils ont eu multics par contre. Par contre ce n'est pas une question d'être relou, tu n'a pas envi de payer pour ce genre de qualité et ni les moyens de valider correctement la livraison.

              Avoir des demandes c'est rigolo et tous les clients en ont.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Autre solution

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

                Je ne connais pas d'unix de Bull.

                Cela s'appelait SPIX, sur les DPX2000 (à l'époque c'était du Geckos sur les DPS pour l'informatique de gestion des années 80…)

                ça en parle sur https://techmonitor.ai/technology/bull_replaces_its_unix_lines_with_integrated_dpx_range

                et oui, ils ont contribué à AIX, vu qu'ils avaient des clones des serveurs IBM (forcément, c'est ce qu'achetait EDF/Gaz de France :p j'en ai fait déployer pas mal à Pacy…)

                Bah Bull était une boîte sympa, z'ont détruit Honeywell ainsi que Zenith Data Systems (qui avait de superbes portables à l'époque….)

                • [^] # Re: Autre solution

                  Posté par  (Mastodon) . Évalué à 3.

                  à l'époque c'était du Geckos sur les DPS

                  Euh, là, c'est plutôt GECOS (General Electric Comprehensive Operation System) que le lézard frétillant.

  • # opentbs

    Posté par  . Évalué à 3.

    Bonjour

    Il existe aussi déjà sous PHP le projet OpenTBS qui se sert de documents LibreOffice pour remplir les documents via PHP.
    Une fois le document généré, rien n'empêche de lancer une ligne de commande shell via PHP pour générer le PDF à partir du document LibreOffice.

    https://www.tinybutstrong.com/opentbs.php?doc

    Bonne journée

  • # Autre solution : Carbone

    Posté par  . Évalué à 5.

    Bonjour,

    En 2011, j'ai fait la même conclusion que vous alors j'ai créé Carbone pour générer tous les documents (PDF, DOCX, EXCEL, CSV, XML, …), minimiser la charge coté développeur et pour laisser nos clients personnaliser eux-mêmes les rapports de notre ERP:

    https://github.com/carboneio/carbone

    Nous l'avons open sourcé après l'avoir perfectionné en production pendant des années pour des grands comptes. Depuis presque 2 ans, c'est devenu une entreprise indépendante. Et depuis moins d'un an, nous sommes 3 personnes à 100% sur ce projet.

    La version open source a toujours une version majeure d'écart et quelques fonctionnalités en moins. Cela dit, le prix de la version Entreprise est très accessible.

    Dans les prochaines semaines, nous allons dévoiler plein de nouveautés :
    - notre propre convertisseur ODT / DOCX -> PDF pour être x200 fois plus performant que LibreOffice pour convertir des documents de 1000 pages en moins de 2 secondes.
    - un tout nouveau studio interactif encore plus accessible et fun
    - un plugin Microsoft
    - un nouveau site web
    - un tutorial interactif

    Nous sommes toujours disponibles sur le chat de notre site https://carbone.io/ alors n'hésitez pas à nous contacter si besoin.

    Cela fait plaisir de voir des solutions similaires émerger :).
    Bonne continuation.

    David Grelaud.

  • # jOpenDocument

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

    Une autre solution, non dépendante de LibreOffice : jOpenDocument

    Cette librairie Java permet de créer, manipuler et remplir des fichiers ODS/ODT..
    et aussi de faire le "rendu" d'un fichier ODS en PDF (mais aussi l'impression et le rendu en bitmap).

    Cette librairie est d'ailleurs utilisée par l'ERP OpenConcerto pour créer tous les documents via modèle ODT (un peu logique, vu que les auteurs sont les mêmes :) )

  • # Utilisation en tant que bibliothèque python ?

    Posté par  . Évalué à 2.

    Merci pour ce projet !

    J'utilise et maintien à coup de sparadrap une solution de ce type : https://github.com/christopher-ramirez/secretary

    Comme relatorio cela fonctionne sur le principe de substitution de chaînes dans le XML. Ça casse régulièrement car même en utilisant des variables bien identifiées dans LibreOffice, il y a toujours une espace insécable ou une balise parasite qui vient se greffer (le plaisir des éditeurs bureautiques). Passer par l'API LibreOffice me semble bien plus robuste et je préfère votre approche (pour peu que l'on veuille bien s'encombrer d'un LibreOffice).

    L'aspect service avec une API est sympa mais souhaitant l'utiliser dans un projet Django (pour lequel il y a déjà un serveur LibreOffice Headless), cela serait plus commode si la couche Flask était dissociée en proposant une bibliothèque Python. Je n'ai pas regardé en détail le code mais il s'agit peut-être « juste » de scinder le code et de créer un autre dépôt.

Suivre le flux des commentaires

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