Pdf.js: Prise en charge des formulaires interactifs (AcroForm)

Il s'agit d'un méta-problème pour le suivi de la prise en charge des formulaires interactifs (AcroForm) conformément au chapitre 8.6 de la référence PDF (https://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7. pdf#page=671&zoom=auto,-246,244).

Il peut être judicieux de baser le travail sur la dernière version de la spécification PDF, juste au cas où il y aurait des différences : http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/ pdfs/PDF32000_2008.pdf#G11.2110737.

Aussi, peut-être une bonne idée d'ajouter un élément TODO « Général » pour assurer une couverture de test appropriée ?

Les deux éléments ont été traités. Merci!

Je pense que nous allons également devoir analyser le contenu du dictionnaire AcroForm , car sinon nous ne pourrons pas, par exemple, charger toutes les ressources de polices nécessaires.
Évidemment, nous ne pouvons pas utiliser de polices personnalisées dans la couche d'affichage, mais nous devrions au moins pouvoir déduire la bonne famille de polices (et des choses comme, par exemple, gras/italique) qui devrait être utilisée et transmettre ces informations à la couche d'affichage.

De plus, pour l'impression de formulaires, nous pourrions peut-être utiliser (ou développer) la fonctionnalité appendToOperatorList déjà existante, mais cela nécessitera certainement que les ressources de police présentes dans le dictionnaire AcroForm aient été chargées.

Une autre chose que nous devrions probablement essayer de prendre en charge est d'utiliser la bonne couleur de texte dans le calque d'affichage (notez que dans Adobe Reader, le texte dans les champs de formulaire de f1040.pdf est bleu). Cela est probablement lié à une meilleure et plus complète prise en charge des flux Appearance .

Enfin, une question générale : pourrons-nous réellement prendre en charge les formulaires de manière significative, sans support de script partiel (et bien aseptisé) ?

Bons points. Je viens de les ajouter à la liste d'articles ci-dessus. Je ne pense pas que nous ayons vraiment besoin d'un support de script car les AcroForms ne nécessitent généralement que le remplissage et l'impression. Les scripts AFAIK ne sont utilisés que pour l'interaction entre les éléments, mais nous pouvons implémenter nous-mêmes les fonctionnalités les plus utilisées (telles que la réinitialisation du formulaire ou les actions des boutons pour l'imprimer). Nous devrons voir à quel point une telle fonctionnalité de script est largement utilisée.

Indicateurs de gestion : multiligne et en lecture seule

Il y a d'autres indicateurs que nous pourrions avoir besoin d'essayer de prendre en charge également, un exemple est comb qui contrôle l'espacement entre les caractères dans un champ de saisie. Celui-ci est en fait utilisé sur la deuxième page de f1040.pdf , voir le champ "Numéro d'identification personnel (PIN)".

Ça semble être une bonne idée. Je l'ai ajouté à la liste.

Ce serait probablement aussi une bonne idée de voir si le code WidgetAnnotation qui construit la propriété fullName peut être nettoyé ou amélioré, voir https://github.com/mozilla/pdf.js /blob/6c263c19946af23b723f148d9f05118971e18b36/src/core/annotation.js#L640 -L670.

De plus, en ce qui concerne les WidgetAnnotation il semble que différents types peuvent avoir des exigences différentes pour l'entrée V dans le dictionnaire d'annotations, il serait donc préférable de récupérer et de valider data.fieldValue dans _each_ sous-classe WidgetAnnotation spécifique.

Le premier point est maintenant dans la liste, pour lequel j'ai quelques idées. J'ai découvert le deuxième point d'un patch que je suis en train de finaliser pour les annotations de widgets de choix, ce sera donc abordé ici.

Salut @timvandermeij
Quand cette fonctionnalité sera-t-elle disponible ? Comment je peux aider?

Nous sommes actuellement en train de l'implémenter, mais il s'agit d'une fonctionnalité importante qui prendra du temps avant qu'elle ne soit terminée. Les cases cochées ci-dessus indiquent quels éléments sont déjà implémentés et pour les autres cases, il existe déjà des demandes d'extraction de travail en cours, nous sommes donc sur la bonne voie avec cette fonctionnalité. N'hésitez pas à le tester en utilisant la branche master et en définissant le paramètre renderInteractiveForms sur true . Il est désactivé par défaut car il n'est pas encore prêt.

Merci Tim, que pouvez-vous me dire sur les signatures numériques ? Il y a des progrès selon ce fil de discussion https://github.com/mozilla/pdf.js/issues/1076

Ceci a été rapporté par l'utilisateur : soa-x a ouvert ce problème le 13 janvier 2012

Près de 5 ans se sont écoulés depuis qu'il a été signalé.

Même quelqu'un a déjà fait une grande partie de la mise en œuvre

viveksjain a commenté le 22 février
@complience Bonjour, j'ai une preuve de concept qui fonctionne sur https://github.com/viveksjain/pdf.js/tree/sig-verify-support. Vous pouvez l'essayer en utilisant git clone --recursive https://github.com/viveksjain/pdf.js.git. Avec un peu plus de travail, il devrait être prêt pour une demande d'extraction dans esta repo, mais je n'ai tout simplement pas encore eu le temps.

Savez-vous si ces offres d'emploi ont été ajoutées aux versions récentes de pdf.js ?

Re : https://github.com/mozilla/pdf.js/issues/7613#issuecomment-251692825

Les signatures dans les fichiers PDF sont un sujet vaste et complexe, qui est quelque peu orthogonal à la mise en œuvre de la prise en charge de base d'AcroForm (c'est ce que _ce_ problème particulier suit).

Le problème actuel est juste un problème de suivi pour la mise en œuvre des fonctionnalités de base d'AcroForm, les signatures sont déjà suivies ailleurs (en #1076, c'est là que cette fonctionnalité devrait être discutée).

@lexcorp Veuillez vous abstenir de publier des informations sans rapport et/ou de poser des questions ici, car cela nuit à l'objectif de ce problème (qui est de suivre la prise en charge des fonctionnalités de base d'AcroForm).
De plus, vous avez maintenant publié essentiellement les mêmes informations dans _trois_ numéros différents, veuillez ne pas spammer le traqueur de problèmes de cette manière !

Bonjour @timvandermeij @Snuffleupagus ,
Nous aimons vraiment votre solution pour ajouter la prise en charge des champs AcroForm. Nous prévoyons d'utiliser ces fonctionnalités dans une application que nous développons actuellement. Nous serions très reconnaissants si vous pouviez nous fournir une date provisoire à laquelle vous seriez en mesure d'ajouter la prise en charge de tous les types de champs de formulaire comme les cases à cocher, etc. et d'exporter les données remplies dans un fichier XFDF ou tout autre format. Merci.

@anujgeek Comme je l'ai déjà mentionné dans https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251699579, il s'agit d'un problème de _suivi_ et pas vraiment un bon endroit pour ce genre de discussion générale et/ ou poser des questions !

Il reste un certain nombre de TODO assez difficiles à implémenter, voir la liste peut-être incomplète ci-dessus, il n'est donc _pas_ possible de donner une estimation du moment, ou même si, cette fonctionnalité sera complètement implémentée.

Notez également que jusqu'à présent, tout le travail a été effectué par des contributeurs, et étant donné que Mozilla remplace PDF.js dans Firefox (voir https://wiki.mozilla.org/Mortar_Project), la prise en charge des formulaires prendra probablement un certain temps.

Il s'agit d'un problème de suivi (voir https://github.com/mozilla/pdf.js/issues/7613#issuecomment-251895091), ce n'est donc pas l'endroit pour discuter ou poser des questions. Contactez-nous sur IRC en cas de questions ou déposez un problème séparé si vous avez trouvé un bogue. Merci.

_(Je déverrouille la conversation pour permettre aux utilisateurs d'utiliser le bouton de réaction pour mesurer l'intérêt pour cette fonctionnalité, mais les commentaires non pertinents seront supprimés.)_

Bonjour ensemble!

Quel est l'état d'avancement du remplissage AcroForm ?
L'exemple utilisé https://www.irs.gov/pub/irs-pdf/f1040.pdf (et autre) ne fonctionne toujours pas. Ou n'est-il pas configuré par défaut ?
Certains JavaScript de base comme définir le ou les champs, effacer les champs, la prise en charge du bouton d'envoi sont-ils mentionnés ?

Merci.

@Alex-DE-74 Veuillez lire attentivement les commentaires ci-dessus, en particulier https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251895091 et https://github.com/mozilla/pdf. js/issues/7613#issuecomment -287907674 sont pertinents.
De plus, vous avez déjà posé ces questions au #9261 (où les réponses ont été fournies) ; s'il vous plaît, essayons de garder ce problème de suivi libre de ce genre de discussion générale.

@Snuffleupagus

Excusez-moi, mais pour moi, ce n'est pas vraiment traçable à travers de nombreux sujets, quel élément a quelle étape. Et les références cycliques ne sont pas du tout utiles. Du point de https://github.com/mozilla/pdf.js/projects/1, il est clair pour moi, quelle pièce d'AcroForms est actuellement prise en charge (complètement) et ce qui est prévu. De plus, de nombreux sujets traitent de l'affichage/de la visualisation, mais pas de mots sur la fonction interactive de remplissage/vérification/sélection/soumission, etc. Ainsi, par exemple, la partie "Widgets de texte" ci-dessus n'a rien sur la "Saisie de texte". Alors, si "AcroForm Dictionary" n'est actuellement pas du tout analysé, comment cela peut-il vraiment bien fonctionner ?
Peut-être qu'il serait utile pour les "utilisateurs" de voir un simple tableau où AcroForm présente ses propriétés et un état de support complet/particulier/planifié répertorié. (pourquoi cela a montré gras =?!)

PS Cela me fait mal, je ne suis pas un expert JS/HTML5, mais j'ai fait beaucoup de choses sur l'autre site (création de PDF avec C#) et je connais aussi d'autres langages de programmation. Cela vaut-il la peine pour moi d'essayer de comprendre le code actuel afin de fournir un support plus interactif et d'aider à développer ce projet ? Ou cela prendra-t-il énormément de temps juste pour comprendre l'architecture actuelle ?

J'ai supprimé le style gras pour vous. Je voudrais souligner à nouveau que ce n'est pas le lieu pour une telle discussion; un canal comme IRC serait plus approprié afin que nous puissions donner quelques informations de base. Remplir/envoyer/imprimer des formulaires est en fait dans la liste des cases à cocher ci-dessus, il n'a tout simplement pas encore été mis en œuvre. La partie « widgets de texte » concerne le rendu des widgets de texte, ce qui signifie les champs de saisie que vous pouvez saisir. C'est fait ; la partie qui reste stocke les valeurs entrées. Tout le monde est le bienvenu pour aider à la mise en œuvre.

BTW : Chrome n'est pas non plus en mesure d'enregistrer des fichiers PDF avec des formulaires, mais il existe une solution de contournement. Les formulaires sont rendus par défaut et on peut les imprimer et on peut même les imprimer au format PDF par défaut, y compris la saisie du formulaire.

Peut-être que cela s'applique également à pdf.js et que nous pouvons simplement utiliser l'enregistrement FF existant au format PDF ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/saveAsPDF ) ?

Je joue avec pdf.js en essayant d'imprimer les valeurs de champ de texte de formulaire saisies. J'ai une preuve de concept de travail rudimentaire où je peux rendre les valeurs saisies au PDF d'impression. Je veux maintenant discuter de mon approche et voir si quelqu'un en propose une meilleure ou plus simple.

Dans mon approche, je transmets les valeurs saisies à la tâche de travail en ajoutant une carte à la tâche. Cette carte est actuellement remplie sur l'événement 'beforeprint'.
Dans la méthode 'getOperatorList' de 'TextWidgetAnnotation', je lis le flux d'objets et remplace l'ancienne valeur de texte de l'opérateur 'Tj' par la nouvelle. Cela fonctionne, mais a beaucoup de problèmes à venir. Le premier est qu'il échoue si le flux n'a pas d'opérateur 'Tj' car le champ n'avait pas de valeur. La seconde est que le placement des alignements autres que «gauche» sera erroné.
L'idée suivante est donc de créer un tout nouveau flux calculant toutes les valeurs par moi-même. Ce sera beaucoup de travail, je voulais donc discuter de cette approche en premier.
Je peux déjà créer un nouveau flux et afficher les valeurs, mais encore une fois, il y a le problème avec les valeurs de décalage de l'opération 'Td'. J'ai creusé un peu le code et je pense que je dois calculer la position de décalage X et Y en tenant compte de la largeur et de la hauteur de la chaîne avec la police donnée. J'ai trouvé le FontDescriptor pour une police intégrée, mais pas pour une police système. Avec le descripteur de police, j'ai la valeur de montée et de descente de la police, avec laquelle je pense pouvoir calculer le décalage y Le décalage x sera fixé pour les textes alignés à gauche, mais doit être calculé pour les textes centrés ou alignés à droite . Je pense que je suis capable de le faire avec le tableau des largeurs de la police xRef, mais encore une fois, il n'y en a pas pour les polices système. Je pense donc que je devrais utiliser un canevas et la méthode measureText.

Donc, comme vous le voyez, il y a beaucoup de « réflexion ». Mais avant d'essayer de mettre en œuvre et de tester mon approche, j'aimerais savoir ce que les autres en pensent.

Il y a quelque temps, nous avons eu une discussion sur la façon dont nous pourrions aborder cela. Reportez-vous à https://mozilla.logbot.info/pdfjs/20161219. L'idée est d'avoir deux listes d'opérateurs différentes : une pour l'interface utilisateur et une pour l'impression. Dans celui pour l'impression, nous remplacerions les opérations basées sur la valeur entrée/sélectionnée dans le widget.

Je pense que c'est un peu plus facile que ce que vous décrivez puisque nous laissons le reste de la logique faire le gros du travail pour nous ; nous devons juste fournir la bonne liste d'opérateurs.

C'est un problème que nous devons résoudre en plusieurs petites étapes. La première étape consiste à rendre le code d'annotation asynchrone, ce qui est fait par @dmitryskey dans #9822. L'étape suivante consisterait à analyser le dictionnaire AcroForm pour, par exemple, les polices et à analyser l'entrée d'apparence par défaut dans le dictionnaire d'annotations pour toutes les informations d'apparence. Pour cela, nous pouvons probablement utiliser l'évaluateur pour obtenir les informations sous forme de liste d'opérateurs, ce qui nécessitait que le code d'annotation soit asynchrone. Ensuite, nous pouvons créer les listes d'opérateurs d'impression pour chaque type d'annotation.

J'ai aussi pensé à créer la liste des opérations par moi-même, mais cela serait plus compliqué pour moi que ma démarche. Je crée simplement le flux d'objets pdf avec 'BMC ... EMC' et passe le flux à l'évaluateur, qui génère la liste d'opérations.
Si je crée moi-même le tableau de la liste d'opérations, j'aurai les mêmes problèmes qu'avec la génération d'un nouveau flux d'objets. Mais à mon humble avis, il est plus compliqué de créer l'oplist que de créer une chaîne et de la convertir en un flux d'objets. Cela fonctionne déjà dans ma preuve de concept.

Je pense qu'Opera/Chrome utilise également pdf.js, mais Opera est capable d'imprimer et d'utiliser les données du formulaire. Peut-être qu'il y a qc. pouvons-nous réutiliser?

Ils utilisent PDFium, qui est principalement du code C++.

Salut à tous, la société pour laquelle je travaille commence à tirer parti de PDFJS et on m'a dit que je devais faire fonctionner "Stockage des valeurs saisies lorsque la page est détruite lorsqu'elle n'est pas visible". Je ne sais pas si ce fil est le bon endroit pour en discuter. @timvandermeij , il semble que vous soyez un moteur majeur de ce projet. Pouvons-nous entrer en contact avec vous ou quelqu'un de la communauté qui pourrait être en mesure de vous aider. J'ai une stratégie pour implémenter cette fonctionnalité, mais je veux m'assurer que ce que je fais peut également être réintégré dans ce référentiel. Nous sommes également prêts à parrainer ou à créer une prime de fonctionnalité, si cela peut aider à faire avancer les choses plus rapidement.

Si vous avez des idées sur la façon de procéder, il est préférable d'ouvrir un numéro séparé pour en discuter. La question principale est que faire des données saisies. Le rendre sur la toile lors de l'impression ? Fournir une option pour télécharger les valeurs au format FDF ? Rendre un nouveau fichier PDF avec les valeurs remplies ? Etc. Cela dépend de ce à quoi l'utilisateur s'attend et de ce que font les autres lecteurs PDF.

Fermeture puisque le support d'AcroForm est maintenant fait et activé. Les numéros restants sont maintenant classés dans des numéros individuels et collectés avec la balise 4-form-acroform ; voir https://github.com/mozilla/pdf.js/labels/4-form-acroform.