Discussion :

[tchize_]

Bonjour,

J'ai besoin de stamper dynamiquement le formulaire d'un ou plusieurs PDF. Je cherche donc un outils capable de lire le contenu des champs d'un formulaire PDF, d'intérpréter ça comme des expression, et de remplacer ensuite ce contenu par le résultat de l'expression.

J'ai déjà une application qui utilise un concurrent de XDOCReport pour générer du reporting pdf / odt / ods à partir de odt / ods. Mais j'ai aujourd'hui on a +- en urgence le besoin de rajouter la possibilité de templates sur base d'un formulaire PDF

Est-ce qu'il y a éventuellement un système de plugin en place dans xdocreport pour ajouter des types de sources / destinations supplémentaires.
L'idée serait de charger les PDF en mémoire, appliquer le moteur velocity ou freemarker sur les Formitem du pdf, et sauver le PDF ainsi généré.

C'est faisable ou je suis partis pour la galère dans cette direction? Et si ce n'est pas faisable avec xdocreport, y a-t-il des outils similaire à xdocreport / JODReports mais prenant un PDF en source?

[azerr]

J'ai déjà une application qui utilise un concurrent de XDOCReport pour générer du reporting pdf / odt / ods à partir de odt / ods.

Je suppose que c'est JODReports + JODConverter.

Est-ce qu'il y a éventuellement un système de plugin en place dans xdocreport pour ajouter des types de sources / destinations supplémentaires.

Si ta source est un format zip (comme odt, docx), XDocReport est modulaire (d'autres types de sources peuvent etre implmentées). XDocREport fournit par exemple une implémentation basique pour pptx

Concernant la destination, XDocReport génère par defaut (source type to source type (docx->docx, odt->odt), mais il est possible de pluguer n'importes quel converter (docx->pdf, odt->pdf, etc).

L'idée serait de charger les PDF en mémoire, appliquer le moteur velocity ou freemarker sur les Formitem du pdf, et sauver le PDF ainsi généré.

J'ai bien peur que ca ne soit pas possible. PDF est un langage binaire et Freemarker/Velocity fonctionne avec du texte. Mais tu as du surement reflechir a la question. Si tu as des choses qui pourraient marcher, je peux voir si XDocReport pourrait intégrer cela.

Angelo

[tchize_]

J'ai bien peur que ca ne soit pas possible. PDF est un langage binaire et Freemarker/Velocity fonctionne avec du texte. Mais tu as du surement reflechir a la question. Si tu as des choses qui pourraient marcher, je peux voir si XDocReport pourrait intégrer cela.

Angelo

Exact, mais il contient du texte au final et itext, en tout cas, permet d'y accéder. On poeux envisager de récupérer les FormItem (formulaire dynamiques PDF), qui seraient remplis avec des trucs du genres "${user.name}", et avec le moteur qui remplacerait par la valeur. Si je posais la question par rapport à xdocreport c'est par ce que ça nous arrangerais, d'un point devu design, d'avoir un moteur unique capable de faire le pdf -> pdf, odt -> pdf, docx -> pdf + éventuellement la conversion vers pdf quand voulu. Mais si c'est un peu trop à bidouiller par rapport aux sources de xdocreport, on se contentera de gérer la version pdf -> pdf à la bourrin en instanciant nous même freemarker

Quand je pense que le problème de départ tout con, c'est que poru ce cas précis qu'on rencontre maintenant, on ne sait pas nous fournir autre chose qu'un PDF en source

[azerr]

Si je posais la question par rapport à xdocreport c'est par ce que ça nous arrangerais, d'un point devu design, d'avoir un moteur unique capable de faire le pdf -> pdf, odt -> pdf, docx -> pdf

Ce qu'il faut bien comprendre avec XDocReport, c'est qu'il fait docx->docx et docx->docx->pdf (et pas docx->pdf directement).

Comme je l'ai deja dit, tu ne pourras pas utiliser Freemarker pour génerer du PDF car PDF est un format binaire.

XDocReport s'appuie sur des format zip qui contient des entries XML (docx, odt, etc). Le principe est de dezipper le docx, odt recuperer les entries XML qui decrivent le document (word/document.xml pour docx, content.xml pour odt). Ces entries XML font figures de template pour Freemarker/Velocity. Le merge entre ces entries XML avec un contexte Java retourne une nouvelle entries XML (qui contient les données Java et plus les $).

Ensuite XDocReport prend les nouvelles entries XML modifiés par Freemarker/velocity et construit un nouveau zip (docx, odt, etc).

Dans ce cas-ci Freemarker/Velocity marche tres bien car on a du texte. Avec PDF, c'est du binaire donc ton champs ${name} ne pourra pas etre detecté par Freemarker. Par exemple si tu ouvres un PDF avec un notepad tu ne verras jamais de ${name}, mais plus un format binaire comme ‰㜳〠删⼠㕆〮㌠‸‰⁒䘯⸶‰ㄴ〠删㸊‾

Mais peut être que tu as une idée et si c'est le cas je suis preneur!

Angelo

[tchize_]

XDocReport s'appuie sur des format zip qui contient des entries XML (docx, odt, etc). Le principe est de dezipper le docx, odt recuperer les entries XML qui decrivent le document (word/document.xml pour docx, content.xml pour odt). Ces entries XML font figures de template pour Freemarker/Velocity.

Evidement, si il faut du zip, c'est coincant. C'est bien ce que j'avais craint en regardant les interfaces dans l'api

Avec PDF, c'est du binaire donc ton champs ${name} ne pourra pas etre detecté par Freemarker. Par exemple si tu ouvres un PDF avec un notepad tu ne verras jamais de ${name}, mais plus un format binaire comme ‰㜳〠删⼠㕆〮㌠‸‰⁒䘯⸶‰ㄴ〠删㸊‾

Oui, enfin, si tu tappe un docx dans notepad, t'as la même chose J'ai jamais parlé de nourrir directement le code source du pdf à freemarker . L'idée c'était de lui fournir le texte des champs du formulaire PDF:


pdf -> formfield -> value (String) -> freemarker -> formfield -> pdf

et ce pour chaque formfield bien sur.

Bref, le remplissage des champs du pdf dynamiquement avec des expressions freemarker ne nous pose a priori pas de soucis, ce que je cherchait c'était de savoir si on savait intégrer ça à un outils faisant déjà les remplissages auto comme source supplémentaire. Comme je disais bidouiller xdocreport dans son coeur ne nous apparait pas une bonne solution, dans le sens ou on doit passer en prod pour le 1er février (vivent les contraintes légales surprises). Je crois qu'on va juste passer par un système à part de notre actuel jodreport avec du code spécifique pour les cas pdf -> pdf

[azerr]

Oui, enfin, si tu tappe un docx dans notepad, t'as la même chose

Oui bien sûr, et c'est pourquoi il y a l'étape dézippage dans XDocReport.

J'ai jamais parlé de nourrir directement le code source du pdf à freemarker . L'idée c'était de lui fournir le texte des champs du formulaire PDF:


pdf -> formfield -> value (String) -> freemarker -> formfield -> pdf

Ah je commence a comprendre ce que tu souhaites faire. Tu veux juste utiliser Freemarker pour merger la veleur d'un formfield avec un context Java et récupérer une string. La chargement du PDF et la reconstruction du PDF n'est pas effectué via Freemarker mais par une autre API Java (laquelle?)

XDocReport lui utilise Freemarker pour génerer le docx, on peut ainsi faire des boucles, des conditions, etc et pas seulement le replacement de valeurs de champs.

Angelo

[tchize_]

Ah je commence a comprendre ce que tu souhaites faire. Tu veux juste utiliser Freemarker pour merger la veleur d'un formfield avec un context Java et récupérer une string. La chargement du PDF et la reconstruction du PDF n'est pas effectué via Freemarker mais par une autre API Java (laquelle?)

itext, ça prend 3 lignes à faire dans chaque sens. Pour ça que je regardais si on pouvais mettre un "plugin itext" en source de xdocreport et le même genre en sortie de xdoc report. De la même manière qu'il y a une source docx, une sources odt, etc

Mais visiblement, ce serait plus une usine à gaz qu'autre chose

[azerr]

Si tu as un exemple de code sous la main, ca serait super sympa de le partager. Merci.

J'aimerais voir si on peut faire qq chose.

Merci!

[tchize_]

Après quelques essais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
    	FileInputStream is = new FileInputStream(new File("source.pdf"));
    	FileOutputStream os = new FileOutputStream(new File("output.pdf"));
    	PdfReader rdr = new PdfReader(is);
 
 
    	PdfStamper stamper = new PdfStamper(rdr, os,'\0',true);
    	for (Map.Entry<String,Item> e : stamper.getAcroFields().getFields().entrySet()){
    		String source = e.getValue().getMerged(0).get(PdfName.TU).toString(); //tooltip
    		String destination = e.getKey(); // todo: generate from source using template engine
    		System.out.println("Setting "+e.getKey()+" from "+source+" to "+destination);
    		stamper.getAcroFields().setField(e.getKey(),destination);
    	}
    	stamper.close();

PdfName.TU permet de récupérer le tooltip d'un champ de formulaire, c'est le seul endroit potable où on a trouvé qu'on pouvait mettre une expression. Dans la value d'origine, c'est difficile car c'est tronqué à la taille du formulaire. Dans le nom du formulaire, ça doit être unique dans le document. Le tooltip n'est pas visible pour l'utilisateur et se prête donc bien à recevoir l'expression

[azerr]

Merci pour l'exemple de code. En effet ca va etre difficile de plugger ca dans XDocReport.

Angelo

[tchize_]

Oui, je crois que ce n'est pas une bonne idée