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.
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.
Les développeurs et développeuses trouveront :
- un exemple d’utilisation très parlant dans la doc ;
- des exemples dans les tests unitaires ;
- la présentation pdf de LoTemplate.
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
- Github (393 clics)
# Tiens...
Posté par Dring . É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. :
Et dans tous les cas, je pourrais sortir du PDF. C'est bien ça ?
[^] # Re: Tiens...
Posté par zozo . É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 zezollo . É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 zozo . É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 Ysabeau 🧶 (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 zozo . Évalué à 2.
Oui, en effet, LoTemplate utilisant LibreOffice tout les format d'export de libreoffice sont possible docx et autre
# Autre solution
Posté par Brokenclock . É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 Dring . É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 BAud (site web personnel) . Évalué à 4.
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)
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 Dring . É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 BAud (site web personnel) . Évalué à 2. Dernière modification le 28 mai 2023 à 22:57.
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 barmic 🦦 . Évalué à 2.
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.
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 BAud (site web personnel) . Évalué à 3.
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 Tonton Th (Mastodon) . Évalué à 3.
Euh, là, c'est plutôt GECOS (General Electric Comprehensive Operation System) que le lézard frétillant.
# opentbs
Posté par totoroavi . É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 dgrelaud . É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 Guillaume Maillard (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 Nim . É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.
[^] # Re: Utilisation en tant que bibliothèque python ?
Posté par PhE . Évalué à 2. Dernière modification le 31 mai 2023 à 21:28.
J'utilise également secretary. Je fais la conversion finale en PDF avec gotenberg.
As-tu publié ta version sparadrap ?
[^] # Re: Utilisation en tant que bibliothèque python ?
Posté par Nim . Évalué à 2.
Pour la version sparadrap, après quelques tentatives avortées d'amélioration de la robustesse, il n'y a pas forcément grand chose d'intéressant :
- quelques filtres jinja supplémentaires ;
- des attributs pour les images permettant de gérer les dimensions ;
- une tentative de message d'erreur plus explicite
https://gitlab.com/iggdrasil/ishtar/-/raw/main/ishtar_common/utils_secretary.py
[^] # Re: Utilisation en tant que bibliothèque python ?
Posté par zozo . Évalué à 3.
oui LoTemplate est bien construit comme cela pour fonctionner en librairie,
https://github.com/Probesys/lotemplate/tree/master/lotemplate
la couche flask utilise la librairie lotemplate donc peut s'intégrer rapidement en librairie.
Par contre attention il faut penser aux dépendances avec LibreOffice
sous debian
echo 'deb http://deb.debian.org/debian bullseye-backports main' > /etc/apt/sources.list.d/backports.list
apt update
apt -y -t bullseye-backports install bash python3 python3-uno python3-pip libreoffice-nogui
[^] # Re: Utilisation en tant que bibliothèque python ?
Posté par Nim . Évalué à 2.
Merci pour ces précisions. La migration vers cette bibliothèque ne va pas être pour tout de suite (d'autant que cela va signifier une migration des templates existants…) mais je l'évaluerai dans les mois à venir.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.