Conversion RTF en PDF et avenir d’iText

Version

6.1.14

Description

Bonjour,

Nous souhaiterions savoir quelles sont vos recommandations pour traduire des fichiers RTF en PDF dans Simplicité. Actuellement nous avons itext intégrer mais nous avions vu dans un ancien post que cette bibliothèque pourrait être dépréciée prochainement.
post

Vous avez mentionné la possibilité d’utiliser Apache PDFBox à l’avenir. Est-ce une direction confirmée ? Si oui, à quelle échéance prévoyez-vous son intégration dans Simplicité, ou existe-t-il d’autres alternatives à considérer dès maintenant pour traduire du rtf en pdf ?

Merci d’avance pour votre retour.

Bien cordialement,

Nous allons retirer la lib iText (très ancienne version 2.1.7, la dernière qui était à priori distribuable librement) dans le cadre de la prochaine version mineure 6.2 (prévue en janvier)

Les composants socle qui utilisaient cette librairie ont été refactorés à cette occasion dans une logique HTML => PDF (via la classe “helper” HTMLToPDFTool qui repose indirectement sur PDFBox).

Rien ne vous empêchera alors d’intégrer spécifiquement les libs iText à jour (commerciales) si c’est votre choix

Ou, si c’est envisageable, d’opter pour une refonte de votre logique RTF => PDF vers du HTML => PDF ou au pire si la source RTF reste un format imposé, dans un post précédent je vous indiquait par exemple la lib com.github.bbottema.rtf-to-html qui permettrait à priori de faire du RTF => HTML => PDF, là aussi il s’agira d’intégrer spécifiquement cette lib car nous n’envisageons pas de l’intégrer au socle, sauf si ce besoin de conversion RTF est plébiscitée (RTF est un format ancien qui remonte à 1987 dont la dernière spécification date de 2008)

Hello David, merci pour ton retour rapide.

Nous avions bien intégrer la lib com.github.bbottema.rtf-to-html à notre projet cela nous a bien permis de générer du html et meme re-réutiliser ce html pour les publications en pdf.

Cependant nous rencontrons à une point bloquant, dans le cas des hyperliens et des tableaux ils ne sont pas pris en compte.
Donc au lieu de faire du RTF => HTML => PDF , nous pensions à tester le RTF => PDF et si nous n’avons pas de perte au niveau du rendu (hyperlink,tableau), directement utiliser le visualisateur de pdf à la place du contenu HTML.

De cela vient ma demande de savoir si le rtf vers le pdf serait supporté directement , en attente d’un retour à bientot :slight_smile:

Une conversion directe RTF=>PDF n’est pas à notre roadmap car c’est un besoin assez spécifique

Si l’approche RTF=>HTML=>PDF ne convient pas il faudrait regarder s’il existe une lib Java libre ou commerciale faisant du RTF=>PDF

Si vous trouvez des libs libres correspondant à votre on peut regarder si elles seraient éligibles à être embarquées dans le socle (les critères étant sa compatibilité vs les autre libs déjà présentes, le fait que ça soit un projet toujours actif, qu’elle soit publiées sur Maven central, qu’elle n’ait pas de vulnérabilité connue, etc.) ou spécifiquement

Bonjour David,
nous avons trouvé cette lib documents4j github, serait elle compatible ?

J’ai aussi vu ce post Convertir un docx en pdf, mais je ne sais pas si il y a eu un retour utilisateur sur cette fonctionnalité.

Nous avions essayé de faire le DOCX => HTML => PDF mais nous perdions les elements de styles, existe-t-il une recommendations en v6.1 ou une méthode plus rapide permettrait de faire du docx => pdf sans passer par le html ? (peut etre docx4j, savoir si le package est sur la dernière version ou dois etre importé via un jar).

Concernant aussi les nouvelles fonctionnalités d’IA de simplicité dans la roadmap, il y avais la traduction des attributs et autre dans un projet, il y aurai-t-il la meme chose concernant les différents formats de document sans explicitement passer par le html ? Cela nous permettrait de renforcer les différentes propositions de nos UseCases et avoir de diversités dans les choix de typage de documents :slight_smile:

Nous maintenons à jour les librairies selon la logique indiquée dans ce document

A ce titre en 6.1 la version de Docx4j est figée en 11.4.11 (cf. Project Dependencies – Simplicite Platform), en 6.2-alpha c’est actuellement la 11.5.0 (cf. Project Dependencies – Simplicite Platform) mais ce sera peut être une version plus récente lors de la release.

Nous n’avons pas d’expérience poussée sur l’usage de cette librairie qu’on utilise pour des choses assez basiques dans la classe helper DocxTool (en l’occurence de la construction de documents from scratch dans une logique HTML to DOCX). Pour d’autres usages de cette librairie autres je pense que le mieux est de solliciter directement de l’aide auprès de l’équipe en charge de cette librairie.

Visiblement il y a aussi des approches de conversion de documents Office dans la lib Apache POI que nous embarquons aussi en standard (cf. les dépendances ci dessus: en version 5.2.5 en 6.1 et actuellement en version 5.3.0 en 6.2-alpha). Nous n’avons pas non plus d’expérience sur un usage de ce type de cette lib, donc là aussi sollicitez les directement pour vous aider.

Bref, je ne suis pas sûr qu’il soit nécessaire à ce stade d’embarquer des librairies additionnelles (ni spécifiquement, ni en standard). Creusez déjà ce que vous pouvez faire avec l’une ou l’autre de ces libs (et n’hésitez pas à partager votre expérience ici pour que ça profite à d’autres et/ou qu’on capitalise sur ce cas d’usage dans nos classes helper)