Je reviens sur cet ancien sujet, juste pour rappeler que remplacer le templating PDF par l’ODT n’est pas possible, ni l’ODT par PDF.
Pourquoi?
Car PDF->ODT est à ma connaissance impossible puisque les fichiers PDF sont vectoriels (c’est un peu le but, avoir un document stable non modifiable prêt à l’impression).
Et ODT->PDF n’est tout simplement pas une solution viable de templating: l’ODT ne se prête pas au templating sérieux à cause de sa tendance à rajouter des métadonnées (ex: vous faites un retour arrière pendant que vous écrivez votre balise qui sera remplacée par une variable, et hop! Ça ne marchera plus, car dans le fichier raw il y a maintenant des balises xml en plein milieu de votre balise/tag, j’ai bien constaté ce problème lorsque j’ai essayé de rénover la librairie odtphp …).
De plus, Dolibarr ne peut fournir un éditeur ODT, donc il faudra que l’utilisateur utilise le sien. Cela a deux conséquences: 1- une dépendance dans un logiciel tiers, dont les spécifications peuvent changer ; 2- impossible de customiser l’interface de l’éditeur pour faciliter les balises, boucles, et autre structures de templating dynamique.
Voilà pourquoi un système de templating HTML/PHP + éditeur HTML (fourni directement avec Dolibarr, et donc modifiable pour rajouter des boutons pour le templating) est la meilleure solution à mon sens. Et c’est pas compliqué à implémenter: prenez une lib de templating, même une des plus simple qui existe, adaptez là pour fonctionner avec Dolibarr, et rajoutez un éditeur HTML. Hop, c’est bouclé. Bien sûr, il faut ensuite polir tout ça pour que ça roule, c’est là que ça prendra bien quelques semaines à quelques mois.
Ce système pourrait également remplacer le templating PDF/PHP actuel si l’on permet d’intégrer du code PHP: soit dans le template HTML avec une balise spéciale, soit avec un système de hook liant vers un fichier PHP, de manière similaire aux hooks ailleurs dans Dolibarr. Car oui, un templating HTML permettrait à mon avis de faire bien plus que le templating ODT actuel, mais il restera limité pour ceux qui veulent vraiment avoir une flexibilité totale. Il faut donc donner cette possibilité même si ce n’est pas très élégant (la règle 80/20: le logiciel doit répondre à 80% des besoins facilement, mais doit laisser la possibilité aux 20% restant de le faire même si c’est plus ardu).
De plus, il y a de nombreux outils de conversion HTML->PDF et quelques uns HTML->ODT, tout ça en PHP donc même pas besoin d’avoir un autre logiciel (comme c’est le cas actuellement pour la conversion ODT->PDF, il y a besoin en général d’installer un serveur Java et LibreOffice sur le serveur, et niveau sécu c’est pas top…).
