Utilisation de XFDF pour le pdf

Question

Quelqu'un a-t-il l'expérience de l'utilisation de XFDF pour les pdf? Y a-t-il des pièges dans l'utilisation de cette approche?

Etape 1 - Je devrais créer un pdf (Adobe Pro) avec des champs en lecture seule qui sont liés aux éléments en XML. Cela agirait comme un gabarit pour trop les données. Étape 2 - Créez des classes personnalisées qui génèrent la chaîne XML XFDF à partir des données de notre base de données. Etape 3 - Lorsqu'un utilisateur demande un fichier pdf, nous récupérons simplement les données de la base de données, construisons la chaîne XFDF et vidons la chaîne dans le navigateur.

Le principal avantage de cette décision architecturale est qu'il n'est pas nécessaire de stocker des fichiers PDF dans la base de données ou sur le disque dur. De plus, j'ai vu de nombreuses implémentations de génération de pdf qui utilisent des processus de lot développés localement qui sont buggés et créent seulement une autre 'partie mobile' dans une application.

Answer 1

J'ai écrit du XFDF, oui. Votre approche semble bonne.

Vous pourriez considérer FDF au lieu de XFDF. FDF peut faire des choses que XFDF ne peut pas ... Vous pouvez ajouter un script (dans les points d'entrée "Avant" F et "Après"), et modifier les apparences du champ. IIRC il y a quelques autres cloches et sifflets, mais ce sont ceux que j'utilise.

Les formes PDF que nous construisons en ont beaucoup de script, et un peu de notre initialisation continue dans "Après" (avec quelques bits dans "Avant"). Un de nos types de champs non standard nécessite également la possibilité de modifier l'apparence d'un champ.

Le problème potentiel de ce type d'approche est les champs de signature. Vous devez enregistrer le fichier PDF pour préserver la validité de la signature. Vous pouvez travailler avec ceci cependant ... juste sauvegarder ces PDFs et quand quelqu'un demande cette instance particulière vous pointez le [X] FDF au formulaire signé plutôt que le modèle non signé.

FDF n'est pas plus difficile à écrire que XML. Il utilise la syntaxe PDF moins la nécessité d'une table xréf et avec un objet racine différent/mise en page.

%FDF-1.2 
1 0 obj 
    <</FDF 
    <</Fields [ 
     <</T(name1)/V(value1)>> 
     << /T (name2) /V (value2) >> 
     <</T(list1) /Opt [ [(display1)(value1)] [(display2)(value2)] ] /v(value2) >> 
     ... 
     ] 
     /F (pathOrURLtoForm.pdf) 
     /JavaScript << 
     /Before (var foo = "blah";) 
     /After(someFunc/(/);) 
     >> 
    >> 
    >> 
endobj 
trailer 
<</Root 1 0 R>> 
%%EOF 

Il y a quelques échappées à faire à divers endroits, mais en général c'est assez simple. iText a une classe FDFWriter qui fera la plupart du travail pour vous, bien que je ne crois pas qu'il supporte tous les cloches et les sifflets FDF.

Answer 2

J'ai utilisé XFDF pour mes projets et la technologie s'est révélée fiable et durable. Tout d'abord parce que c'est XML, je pourrais compresser le XML et les stocker de manière persistante avec un faible encombrement. Comme Mark Storer l'a expliqué ci-dessus, il y a des limitations que XFDF ne peut pas faire qui est un script de support. Si vous avez besoin d'une bibliothèque qui fusionne le champ XFDF/FDF, vous pouvez essayer GEM [nguyen][https://github.com/joneslee85/nguyen].