Nouveau système de templating ODT et PDF

Bonjour à tous,

Je vais ici discuter de futures possibles implémentations de remplacement du système de templating ODT et PDF actuels, qui a deux problèmes:
- Non unifié: les ODT et PDF sont générés par deux codes totalement différents, et il est difficile de faire le lien quand on est intégrateur (obligé de faire deux templates: un pour ODT et un pour PDF).
- Difficiles à mettre en oeuvre: un template PDF pour chaque module Dolibarr.
- Peu de flexibilité: les fonctions de substitutions et les hooks permettent de pallier un peu à ce problème, mais la librairie ODT utilisée est limitée en terme de fonctionnalités et ne permet pas de répondre à tous les besoins, ce qui oblige à recourir au templating PDF qui est lui par contre très flexible mais très compliqué.

À la suite des discussions au sujet d’un remplacement du système de templating ODT et PDF:


http://www.dolibarr.org/forum/11-suggest-new-features/21235-an-easy-way-to-modify-pdf-templates#21261

Il semble que maintenant la librairie odtPHP (celle utilisée par Dolibarr) est belle et bien morte, puisque le site dédié n’existe plus:
http://www.odtphp.com

Néanmoins il est toujours possible d’accéder aux sources sur Sourceforge, les dernières modifications datant de 2009:


Il y a cependant des alternatives, notamment les plus intéressantes que j’ai pu trouver:

  • TBS OOo et OpenTBS (le successeur de TBS OOo): parfait remplacement pour odtPHP. Gros avantages: supporte non seulement les ODT mais aussi doc et docx ainsi que les calc .xls et .ods, est toujours en développement, et est TRES flexible car basé sur le moteur TinyButStrong. Defauts: requiert TinyButStrong et Zlib.
  • PHP-ODT-XSLT est une librairie qui peut convertir un odt en html, on pourrait donc générer un PDF à partir du fichier HTML résultant, faisant ainsi la jonction entre ODT et PDF: il suffira de faire un modèle ODT pour pouvoir le générer en PDF.
  • html2pdf: pour convertir un PDF en HTML (voir post référencé au début)
  • PDML: système de templating très simple pour faire des modèles PDF en utilisant TCPDF (voir post référencé au début).

Techniquement, je pense qu’il est possible d’utiliser ces nouveaux outils de deux façons:
- Soit on utilise la librairie OpenTBS pour générer les documents ODT et Word, et en utilisant html2pdf on les convertit en PDF (on peut aussi utiliser la méthode WriteHTML de TCPDF). C’est la meilleure solution sur le long terme, mais c’est aussi celle qui requiert le plus grand investissement en terme de temps, car il faut tout refaire.
- Soit on implémenter PDML au-dessus de TCPDF. Cela ne devrait pas requérir beaucoup d’investissement puisque le système de templating PDF fonctionne déjà avec TCPDF, et que PDML est juste une couche d’abstraction supplémentaire. C’est une bonne solution sur le moyen terme et enlèverait au moins les frustrations du templating PDF avec Dolibarr.


En conclusion, ce post n’a que pour but de recenser les alternatives actuellement disponibles et de proposer des solutions pour le futur.


Annexe: d’autres projets intéressants:
http://code.google.com/p/images2odt/
http://esafwan.posterous.com/image2odt-convert-multiple-images-to-odt
PrinceXML

Sur les 4-5 intégrations de dolibarr j’ai réalisé cette année, j’ai eu à chaque fois des modifications à apporté soit sur les factures, soit sur des docs.
Et pour m’être coltiné des modifs dans les docs pdf de dolibarr et en avoir même crée pour certains de mes modules, je peux assuré que c’est la plaie, qu’il n’est pas normal qu’un développeur soit obligé de le faire et qu’il est effectivement urgent de faire quelque-chose de mieux!

La question qui se pose alors est effectivement de savoir quoi?

D’abord ce serait pas mal de ne faire qu’un seul truc (soit de l’odt, soit du pdf, soit autre chose) et j’avoue ne pas être un fan de l’odt car il peu y avoir des « subtilités » lors de l’impression selon l’imprimante alors disponible… le pdf est fait pour garantir le format d’impression. Cependant le mode de fonctionnement de l’odt par template est un bon mode de fonctionnement.

Ce qui me fait pousser un modèle de fonctionnement suivant :
on génère du pdf à partir d’un template se basé sur un fichier XML de description… idéalement avec un chtit mode « wysiwig »
il faudrait voir ce que l’on trouve dans d’autres solutions, sachant qu’il n’y a pas de honte à copier ce qui fonctionne bien chez d’autres …

@defrance: dans ce cas la meilleure solution pour vous serait d’utiliser la librairie PDML qui est exactement ce que vous recherchez.

Cependant, ODT est également un système de templating basé sur une syntaxe XML et est beaucoup mieux documenté, donc au final, en utilisant un système ODT->HTML->PDF cela reviendrait à peu près à la même chose, mais avec effectivement une étape intermédiaire de conversion qui pourrait résulter en des bizarreries, mais qui néanmoins unifierait le système.

Dans l’idéal, on chercherait un langage de type XML qui pourrait s’éditer visuellement, mais qui résulterait en des PDF ou des ODT au choix, mais malheureusement à ma connaissance, aucune solution de ce type n’existe.

Une autre alternative serait de coder un éditeur WYSIWYG pour PDML, ce qui permettrait de créer des modèles PDF aussi simplement que des modèles ODT.

Quel dommage que le projet n’est pas abouti …

Pouvoir custom son template PDF facile sera le TOP !

Odt … pdf … ******** prise de tete pour afficher correctement un modèle digne de se nom sans etre codeur …

Pour un codeur, c’est deja une plaie lool alors pour un novice :wink: … sans commentaires …

Patience, je réfléchis déjà à un myPrint pour cette année…

Bonsoir,
Même si l’esthétique n’est pas la priorité, il est vrai que les factures émises devraient être réglementaire et tout et tout.
Si on fait de l’international, il manque déjà les mentions pour la tva (je viens de réagir sur le sujet)
Je reviens donc sur mon idée qu’il doit y avoir une équipe qui bosse sur le réglementaire. un logiciel qui répond « réglementaire » ça rassure !
@+

J’ai également des choses dans les cartons concernant le templating pdf…

Ah :happy:

J’ai hate de voir cela …

Ca urge sérieusement …

Bon messieurs, action :happy:

Dolibarr est out depuis quelques années, vous avez la capacité de lui redonner une jeunesse :happy:

Et n’oubliez pas … c’est un logiciel « communautaire », gratuit, et open source … :wink:

lol… no comment

Bonjour,
Je pense effectivement qu’il est possible de mieux faire.
Donc je suis aller voir du côté d’OpenConcerto (au hasard).
Les modèles de documents sont des tableaux openDocument contenant les Etiquettes et le formatage. Y sont associés un document XML qui définit quel champ va dans quel case du tableau. Exemple :
<element location="B1" type="fill"> <field base="Common" table="SOCIETE_COMMON" name="TYPE" /> <field base="Common" table="SOCIETE_COMMON" name="NOM" /> </element>
Pour les lignes du document, on a un objet « table » avec des colonnes :

[code]

...[/code] Lors de la génération du document, on retrouve à la fois un .ods et un PDF. Sous le capot, je ne suis pas allé voir, c'est en java.

Bonjour,
Un autre exemple : Magento.
Je ne suis allé voir que sous le capot.
L’outil est écrit en php/Zend. Pour au moins certains documents, des PDF sont générés en utilisant une fonction interne de Zend, mais le contenu est mis en place par programmation. On est donc proche du fonctionnement de Dolibarr.
Extrait du code

public function getPdf($shipment = null)
    {
        $this->_beforeGetPdf();
        $this->_initRenderer('shipment');

        $pdf = new \Zend_Pdf();
        $this->_setPdf($pdf);
        $page = $this->newPage();
...
        $page->setFillColor(new \Zend_Pdf_Color_GrayScale(0.5));
        $page->setLineColor(new \Zend_Pdf_Color_GrayScale(0.5));
        $page->setLineWidth(0.5);
        $page->drawRectangle(25, 790, 570, 755);
        $page->setFillColor(new \Zend_Pdf_Color_GrayScale(1));
        $page->drawText(__('Packages'), 35, 770, 'UTF-8');
        $page->setFillColor(new \Zend_Pdf_Color_Rgb(0.93, 0.92, 0.92));

Bonjour à tous,

avez-vous avorté ou plutôt mûrement réfléchi ?

Aviez-vous lu les sujets de Raphael sur Github
https://github.com/Dolibarr/dolibarr/issues/3499

The idea is to provide a generic feature to avoid custom developments as much as possible.
The current implementation displays « global » extrafields just where the public note would be or below it if it’s set and « line » extrafields just below the description.
The code is here for you to see:
https://github.com/GPCsolutions/dolibarr/commit/a2536742c8afcd1c2f6965b9d4267295a3175c4a

Bonsoir,
J’avance à grand pas sur mon projet de génération pdf à partir d’une description xml (apparemment Defrance a eu la même idée).
C’est déjà en production chez quelques clients pour la partie tableau de lignes.
N’en déplaise à Fabien, ce ne sera pas gratuit vu que mon boucher et mon boulanger ne veulent toujours pas m’offrir ma nourriture !

ché quoi d’ça ? à partir d’une description xml… un pdf ? uh ?
faudra beaucoup d’explications pour me faire casquer !
et faudrait que ce soit pas figé sur une seule version :wink:

Pourquoi vous avez pas fait un module commun, en financement participatif ?
ce truc, c’est demandé par 90% des péqueno (comme moi) sur le forum. et 100% des pas-péqueno-mais-pas-dév (comme moi aussi) qui l’ont pas demandé et ont essayé eux-même…
Se sont cassés les dents et ont fait une indigestion de doliprane, puis une crise sur le forum.

Ou alors, mettez en commun les efforts, additionnez les temps de travail + marge (parce que le boucher et le boulanger margent aussi !), et vendez le en participatif pour intégration au core ? :s

parce que pour faire avancer une charrette tirée par deux chevaux, il faut un cocher sinon il y a un cheval qui part a droite et l’autre a gauche ^^

De mon coté c’est plutot à petit pas que j’avance, j’ai d’autres devs à finir avant de me lancer sur celui-ci, sans doute courant mai.
Ensuite tous le monde ne souhaite pas forcément passer par un financement participatif, ce qui est mon cas pour plein de raisons
Enfin qu’il y ai non pas un mais deux nouveaux système de création de pdf va dans le bon sens car il permet d’explorer des solutions techniques différentes et la sélection naturelle conservera la meilleure…

Bonjour,
Je tombe sur votre post par hasard justement en cherchant une solution pour nos factures et propale, pour l’instant on utilise Ultimate PDF mais cela ne répond pas tout à fait à nos besoins.

Un éditeur WYSIWYG intégré serait vraiment une solution pour tout le monde, et nous sommes prêt à participer à un financement participatif comme pour le module comptabilité (alors que nous ne l’utilisons pas), car je considère que cela doit faire parti du core et non un module payant supplémentaire.

Bonjour,

Vu le temps déjà passé à coder et celui restant, on est sur un projet à 30 jours/homme minimum, ce qui représenterait à vue de nez 15000 euros à trouver en financement participatif… autant dire que ça risquerait de prendre un certain temps !

Surtout que si le développement est également ouvert à d’autres codeurs, il faut rajouter du temps de gestion de projets, de conflits de points de vue technique (on est sur du lourd là), etc…

C’est pour ça que j’ai choisi de mener seul ce projet qui me trotte dans la tête depuis des années et de le mener avec ma vision, tout en réfléchissant en parallèle à un moyen de le rentabiliser.

J’ai regardé pdml et cela semble très succin en terme de saut de page, gestion des lignes…

Pour ma part j’ai commencé à travailler sur l’aspect description XML des balises utilisables dans un générateur, pour les fonctionnalités, je me suis « librement » inspirée de ce qu’il ce fait avec Access et crystal report (pour ceux qui ce rappel de cette bouse) en terme de fonction de pagination.
il sera par exemple possible de créer des listes et des « sous-états »

Bonjour
J’avais jeté un oeil sur https://github.com/dompdf/dompdf car on sait éditer de l’html en wysiwyg

Fred