Bonjour,

je ne trouve aucune librairie open-source ni solution qui me permette de générer un fichier PDF au format A-3b qui est l'une des dernières évolutions ( PDF1.7 et qui permet de joindre des fichiers sans que l'on ne le voit visuellement, comme si vous rajoutiez un fichier à un mail.

Le but est de joindre un fichier XML à ce PDF qui contiendra les mêmes informations mais si le PDF est lisible par un "humain" le XML sera interprété par des plateforme c'est ce qui va être utilisé pour les factures dématérialisées Factur-X.

J'apprécierais un bon Dev en C# qui pourrait m'aider car j'ai plusieurs librairies dont certaines payantes mais je n'ai pas réussi à trouver de fonction pour attacher le fichier dans le PDF...

Merci beaucoup 

a priori il y a ce package nuget https://www.nuget.org/packages/ZUGFeRD-csharp/#readme-body-tab 

 https://github.com/stephanstapel/ZUGFeRD-csharp/ 

Edit: autre page qui peut être intéressante : http://fnfe-mpe.org/hackathon-factur-x/ 

-
Edité par umfred 27 juillet 2023 à 19:42:22

Bonsoir, merci, en effet je suis passé par ce nugget qui crée le xml essentiellement, mais qui ne joint pas le pdf et le XML.

J'ai même été en contact avec le créateur du nugget qui m'a renvoyé sur le consortium PDF etc ... iText7, évolution de de iTextSharp, PDFSharp ont dans leurs projets d'évolution le traitement des PDF/A-3b mais ce n'est pas encore dans la version actuelle. 

Bref la seule solution OpenSource aujourd'hui est un script Python que je n'arrive pas à convertir en exe, mais ce n'est pas l'objet de ce forum, je voudrais vraiment faire du tout c#. J'ai l'impression que je vais devoir créer par moi même ces fonctions et vu mon niveau ... ce n'est pas gagné.

un script python se lance en installant python, il n'y a pas de "vrai" exe avec python.
La norme 3b est peut-être trop récente, A voir ce qui la différencie vraiment de la 3 qui permet déjà d'inclure le xml

(sur la page github, il y a un lien vers un sujet SO qui semble indiqué l'écriture du xml dans le pdf avec iTextSharp https://github.com/stephanstapel/ZUGFeRD-csharp/#writing-xml-attachments-to-pdf-files )

ou il se faut se faire les dents en utilisant la description du fichier de la norme 

-
Edité par umfred 28 juillet 2023 à 13:25:08

Bonjour et merci pour ces retours. le nugget de stephan est la première librairie que j'ai trouvée et testée. Elle permet de générer un xml, mais je n'ai pas sû trouver l'intégration du xml dans le PDF, j'ai même échangé avec lui directement. 

iTextSharp ne gère pas le format PDF/A-1 ni les suivants, et elle n'évoluera pas puisqu'elle est remplacée par iText7. J'ai testé mais sans succès non plus.

J'en suis à la création du fichier par moi même et je me heurte à un autre problème.

Je suis loin d'être habitué au C# donc ça n'aide pas, il y a des fonctions que j'utilise sans trop les comprendre et je suis tombé sur des incohérences entre les exemples et la réalité. Le simple AttachXMLFile qui sonne bien mais qui n'existe tout simplement pas par exemple dans une autre librairie payante mais testable.

Donc j'en suis à créer mon fichier PDF par moi même et je suis arrivé à coincer mon XML dans un PDF sans aucune libraire spécifique au PDF, en rajoutant une partie de texte avec StringBuilder qui contient mon xml et en mettant les balises pdf etc ... donc ça progresse.

Reste à savoir comment et ou l'insérer dans n'importe quel PDF, mais aussi à le compresser. 

Je coince sur la deuxième partie. Je m'explique, le fichier PDF est de type utf-8 (il me semble) et on le crée avec des balises spécifiques /PDF 1 0 obj etc ... et donc on créer un "objet" fichier embedded et on devrait, au lieu de l'écrire en xml en clair, le compresser en Deflate. Et je n'arrive pas à écrire les codes des caractères de compression comme il se doit. Ils s'écrivent comme des caractères courants ou des codes hexa alors qu'il faudrait y voir des caractères complexes (comme quand on ouvre un fichier exe ou zip avec un notepad). 

Peut-être que StringBuilder n'est pas la bonne méthode ? 

A bientôt,

David

>Peut-être que StringBuilder n'est pas la bonne méthode ?

Je pense moi aussi que ce n'est pas la bonne méthode.

J'y connais rien en librairie pour PDF.

Mais la description de vos "problèmes" laisse quand même penser à l'encodage de chaine UTF-16 interne à .NET et StringBuilder a été pensé pour simplifier l'encode-décodage des chaines de caractère selon plusieurs standards d'encodage.

Pour des traitements sur des données compressées, je pencherais plutôt sur des tableau de "Byte" et pas des chaines de caractères.