Pdf.js: Unterstützung für interaktive Formulare (AcroForm)

Dies ist ein Metaproblem zur Verfolgung der Unterstützung interaktiver Formulare (AcroForm) gemäß Kapitel 8.6 der PDF-Referenz (https://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7. pdf#page=671&zoom=auto,-246,244).

Es könnte eine gute Idee sein, die Arbeit stattdessen auf der neuesten Version der PDF-Spezifikation zu basieren, falls es Unterschiede gibt: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/ pdfs/PDF32000_2008.pdf#G11.2110737.

Vielleicht ist es auch eine gute Idee, einen "Allgemeinen" TODO-Punkt zum Sicherstellen einer angemessenen Testabdeckung hinzuzufügen?

Beide Punkte wurden angesprochen. Dankeschön!

Ich denke, dass wir auch den Inhalt des AcroForm Wörterbuchs tatsächlich parsen müssen, da wir sonst zB nicht alle notwendigen Font-Ressourcen laden können.
Natürlich können wir keine benutzerdefinierten Schriftarten in der Anzeigeebene verwenden, aber wir sollten in der Lage sein, zumindest die richtige Schriftfamilie (und Dinge wie zB fett/kursiv) abzuleiten, die verwendet werden soll, und diese Informationen an die Anzeigeebene weiterzugeben.

Außerdem können wir zum Drucken von Formularen möglicherweise die bereits vorhandene appendToOperatorList Funktionalität verwenden (oder darauf aufbauen), aber das erfordert definitiv, dass die im AcroForm Wörterbuch vorhandenen Schriftressourcen geladen wurden.

Eine andere Sache, die wir wahrscheinlich versuchen sollten, ist die Verwendung der richtigen Textfarbe in der Anzeigeebene (beachten Sie, dass der Text in den Formularfeldern von f1040.pdf im Adobe Reader blau ist). Dies hängt wahrscheinlich mit einer besseren und umfassenderen Appearance Stream-Unterstützung zusammen.

Abschließend noch eine allgemeine Frage: Werden wir Formulare ohne partielle (und gut bereinigte) Skriptunterstützung tatsächlich sinnvoll unterstützen können?

Gute Argumente. Ich habe sie gerade der Artikelliste oben hinzugefügt. Ich glaube nicht, dass wir wirklich Skriptunterstützung brauchen, da die AcroForms im Allgemeinen nur ausgefüllt und gedruckt werden müssen. AFAIK-Skripte werden nur für die Interaktion zwischen Elementen verwendet, aber wir können die am häufigsten verwendeten Funktionen selbst implementieren (wie das Zurücksetzen des Formulars oder Schaltflächenaktionen zum Drucken). Wir müssen sehen, wie weit verbreitet solche Skriptfunktionen sind.

Handle-Flags: mehrzeilig und schreibgeschützt

Es gibt andere Flags, die wir möglicherweise ebenfalls ausprobieren und unterstützen müssen, ein Beispiel ist comb das den Abstand zwischen den Zeichen in einem Eingabefeld steuert. Dieser wird tatsächlich auf der zweiten Seite von f1040.pdf , siehe Feld "Persönliche Identifikationsnummer (PIN)".

Klingt wie eine gute Idee. Ich habe es der Liste hinzugefügt.

Es wäre wahrscheinlich auch eine gute Idee zu prüfen, ob der WidgetAnnotation Code, der die fullName Eigenschaft erstellt, bereinigt oder verbessert werden kann, siehe https://github.com/mozilla/pdf.js /blob/6c263c19946af23b723f148d9f05118971e18b36/src/core/annotation.js#L640 -L670.

Auch in Bezug auf WidgetAnnotation s scheint es, dass verschiedene Typen unterschiedliche Anforderungen für den Eintrag V im Anmerkungswörterbuch haben können, daher ist es möglicherweise besser, data.fieldValue in _each_ abzurufen und zu validieren. bestimmte WidgetAnnotation Unterklasse.

Der erste Punkt steht jetzt in der Liste, für den ich einige Ideen habe. Ich habe den zweiten Punkt in einem Patch erfahren, den ich derzeit für Auswahl-Widget-Anmerkungen abschließe, sodass er dort behandelt wird.

Hey @timvandermeij
Wann wird diese Funktion verfügbar sein? Wie kann ich helfen?

Wir sind derzeit dabei, dies zu implementieren, aber es ist ein großer Teil der Funktionalität, der einige Zeit in Anspruch nehmen wird, bis er vollständig ist. Die angekreuzten Kästchen oben zeigen, welche Elemente bereits implementiert sind und für andere Kästchen gibt es bereits in Arbeit befindliche Pull-Requests, sodass wir mit dieser Funktionalität auf dem richtigen Weg sind. Sie können es gerne testen, indem Sie den Zweig master und den Parameter renderInteractiveForms auf true . Es ist standardmäßig deaktiviert, da es noch nicht bereit ist.

Danke Tim, was kannst du mir über digitale Signaturen sagen? Es gibt Fortschritte laut diesem Diskussionsthread https://github.com/mozilla/pdf.js/issues/1076

Dies wurde vom Benutzer gemeldet: soa-x hat dieses Problem am 13.01.2012

Fast 5 Jahre sind seit der Meldung vergangen.

Sogar jemand hat schon viel von der Umsetzung gemacht

viveksjain kommentierte am 22. Februar
@complience Hallo, ich habe einen Proof-of-Concept unter https://github.com/viveksjain/pdf.js/tree/sig-verify-support. Sie können es versuchen, indem Sie git clone --recursive https://github.com/viveksjain/pdf.js.git verwenden. Mit etwas mehr Arbeit sollte es bereit sein für einen Pull-Request in Esta Repo, aber ich hatte einfach noch keine Zeit.

Wissen Sie, ob diese Jobs neueren Versionen von pdf.js hinzugefügt wurden?

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

Signaturen in PDF-Dateien sind ein großes und komplexes Thema, das etwas orthogonal zur Implementierung der grundlegenden AcroForm-Unterstützung ist (was _dieses_ Problem verfolgt).

Das aktuelle Problem ist nur ein Tracking-Problem für die Implementierung grundlegender AcroForm-Funktionen, Signaturen werden bereits an anderer Stelle verfolgt (in #1076, wo diese Funktion diskutiert werden sollte).

@lexcorp Bitte posten und/oder Fragen zu stellen, da dies dem Zweck dieses Problems (der Unterstützung für grundlegende AcroForm-Funktionen nachzuverfolgen) abträglich ist.
Außerdem haben Sie jetzt im Grunde die gleichen Informationen in _drei_ verschiedenen Issues gepostet, bitte spammen Sie den Issue Tracker nicht auf diese Weise!

Hallo @timvandermeij @Snuffleupagus ,
Ihre Lösung zum Hinzufügen von Unterstützung für AcroForm-Felder gefällt uns sehr gut. Wir planen, diese Funktionen in einer App zu verwenden, die wir derzeit entwickeln. Wir würden uns sehr freuen, wenn Sie uns ein vorläufiges Datum nennen könnten, an dem Sie Unterstützung für alle Arten von Formularfeldern wie Kontrollkästchen usw. hinzufügen und die ausgefüllten Daten in eine XFDF-Datei oder ein anderes Format exportieren können. Vielen Dank.

@anujgeek Wie ich bereits in https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251699579 erwähnt habe, ist dies ein _tracking_-Problem und kein wirklich guter Ort für diese Art von allgemeiner Diskussion und/ oder Fragen stellen!

Es gibt noch eine Reihe ziemlich schwierig zu implementierender TODOs, siehe die möglicherweise unvollständige Liste oben, daher ist es _nicht_ möglich, irgendeine Art von Schätzung abzugeben, wann oder sogar ob diese Funktion vollständig implementiert wird.

Beachten Sie auch, dass die gesamte Arbeit bisher von Mitwirkenden geleistet wurde und da Mozilla PDF.js in Firefox ersetzt (siehe https://wiki.mozilla.org/Mortar_Project), wird die Formularunterstützung höchstwahrscheinlich eine Weile dauern.

Dies ist ein Tracking-Problem (siehe https://github.com/mozilla/pdf.js/issues/7613#issuecomment-251895091), daher ist dies nicht der Ort für Diskussionen oder Fragen. Kontaktieren Sie uns bei Fragen im IRC oder melden Sie ein separates Problem, wenn Sie einen Fehler gefunden haben. Vielen Dank.

_(Ich schalte die Konversation frei, damit Benutzer die Reaktionsschaltfläche verwenden können, um das Interesse an dieser Funktion zu messen, aber irrelevante Kommentare werden entfernt.)_

Hallo zusammen!

Wie ist der Fortschritt bei der AcroForm-Füllung?
Verwendetes Beispiel https://www.irs.gov/pub/irs-pdf/f1040.pdf (und andere) funktioniert immer noch nicht. Oder ist es nicht standardmäßig konfiguriert?
Einige grundlegende JavaScripts wie Felder setzen, Felder löschen, Unterstützung für Sendeschaltflächen erwähnt?

Vielen Dank.

@Alex-DE-74 Bitte lesen Sie die obigen Kommentare sorgfältig durch, insbesondere https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251895091 und https://github.com/mozilla/pdf. js/issues/7613#issuecomment -287907674 relevant sind.
Darüber hinaus haben Sie diese Fragen bereits in #9261 gestellt (wo Antworten gegeben wurden); Bitte lassen Sie uns versuchen, dieses Tracking- Problem von dieser Art von allgemeiner Diskussion fernzuhalten.

@Snuffleupagus

Entschuldigung, aber für mich ist es bei vielen Themen nicht wirklich nachvollziehbar, welcher Artikel welche Stufe hat. Und zyklische Verweise sind überhaupt nicht hilfreich. Ab https://github.com/mozilla/pdf.js/projects/1 ist für mich klar, welcher Teil von AcroForms jetzt (vollständig) unterstützt wird und was in Planung ist. Darüber hinaus befassen sich viele Themen mit dem Wiedererkennen/Anzeigen, aber keine Worte über die interaktive Funktion Füllen/Prüfen/Auswählen/Absenden usw. So hat beispielsweise der obige Teil "Text-Widgets" nichts über "Texteingabe". Wenn "AcroForm Dictionary" derzeit überhaupt nicht geparst wird, wie kann es dann wirklich gut funktionieren?
Vielleicht wäre es für "Benutzer" hilfreich, eine einfache Tabelle zu sehen, in der AcroForm mit ihren Eigenschaften und einem Status der gesamten/besonderen/geplanten Unterstützung aufgeführt ist. (Warum wurde dies fett angezeigt =?!)

PS Es tut mir leid, ich bin kein JS/HTML5-Experte, habe aber viele Dinge auf der anderen Seite gemacht (PDF mit C# erstellen) und bin auch mit anderen Programmiersprachen vertraut. Ist es mir wert zu versuchen, den aktuellen Code zu verstehen, um mehr interaktive Unterstützung zu bieten und bei der Entwicklung dieses Projekts zu helfen? Oder wird dies viel Zeit in Anspruch nehmen, nur um die aktuelle Architektur zu verstehen?

Ich habe den fetten Stil für Sie entfernt. Ich möchte noch einmal betonen, dass dies nicht der Ort für eine solche Diskussion ist; ein Kanal wie IRC wäre besser geeignet, damit wir einige Hintergrundinformationen geben können. Das Ausfüllen/Absenden/Drucken von Formularen ist zwar in der obigen Checkbox-Liste, es wurde nur noch nicht implementiert. Beim "Text-Widgets"-Teil geht es um das Rendern von Text-Widgets, d. h. die Eingabefelder, die Sie eingeben können. Das ist erledigt; der verbleibende Teil speichert die eingegebenen Werte. Jeder ist herzlich eingeladen, bei der Umsetzung mitzuhelfen.

Übrigens: Chrome kann auch keine PDFs mit Formularen speichern, aber es gibt einen Workaround. Formulare werden standardmäßig gerendert und man kann sie drucken und man kann sie sogar standardmäßig als PDF drucken, einschließlich der Formulareingabe.

Vielleicht gilt dies auch für pdf.js und wir können einfach das vorhandene FF-Speichern als PDF verwenden ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/saveAsPDF )?

Ich spiele mit pdf.js herum und versuche, eingegebene Formulartextfeldwerte zu drucken. Ich habe einen rudimentären Arbeitsnachweis, mit dem ich eingegebene Werte in das Druck-PDF rendern kann. Ich möchte jetzt meinen Ansatz diskutieren und sehen, ob jemand einen besseren oder einfacheren hat.

In meinem Ansatz übergebe ich die eingegebenen Werte an die Worker-Aufgabe, indem ich der Aufgabe eine Map hinzufüge. Diese Karte wird derzeit auf der "Beforeprint"-Veranstaltung gefüllt.
In der Methode 'getOperatorList' der 'TextWidgetAnnotation' lese ich den Objektstrom und ersetze den alten Textwert des 'Tj'-Operators durch den neuen. Das funktioniert, bringt aber viele Probleme mit sich. Der erste ist, dass es fehlschlägt, wenn der Stream keinen 'Tj'-Operator hat, weil das Feld keinen Wert hatte. Der zweite ist, dass die Platzierung für andere Ausrichtungen als 'links' falsch ist.
Die nächste Idee ist also, einen komplett neuen Stream zu erstellen, der alle Werte selbst berechnet. Dies wird eine Menge Arbeit sein, daher wollte ich diesen Ansatz zuerst besprechen.
Ich kann bereits einen neuen Stream erstellen und die Werte anzeigen, aber auch hier gibt es das Problem mit den Offset-Werten der Operation 'Td'. Ich habe mich ein wenig in den Code vertieft und denke, dass ich die Offset-X- und Y-Position berechnen muss, indem ich die Breite und Höhe des Strings mit der angegebenen Schriftart berücksichtige. Ich habe den FontDescriptor für eine eingebettete Schriftart gefunden, aber nicht für eine Systemschrift. Mit dem Font-Deskriptor habe ich den Auf- und Abstiegswert der Schrift, mit dem ich glaube, den y-Offset berechnen zu können . Ich denke, ich kann dies mit dem widths-Array des Font xRef tun, aber auch hier gibt es keine solche für Systemfonts. Ich denke, ich müsste eine Leinwand und die Methode measureText verwenden.

Wie Sie sehen, wird viel „nachgedacht“. Aber bevor ich versuche, meinen Ansatz umzusetzen und zu testen, würde ich gerne wissen, was andere davon halten.

Vor einiger Zeit hatten wir eine Diskussion darüber, wie wir das angehen könnten. Siehe https://mozilla.logbot.info/pdfjs/20161219. Die Idee ist, zwei verschiedene Bedienerlisten zu haben: eine für die Benutzeroberfläche und eine für den Druck. In der zum Drucken würden wir Operationen basierend auf dem eingegebenen/ausgewählten Wert im Widget ersetzen.

Ich denke, dies ist etwas einfacher als das, was Sie beschreiben, da wir die verbleibende Logik die schwere Arbeit für uns erledigen lassen; wir müssen nur die richtige Betreiberliste bereitstellen.

Dies ist ein Problem, das wir in mehreren kleinen Schritten lösen müssen. Der erste Schritt besteht darin, den Anmerkungscode asynchron zu machen, was von @dmitryskey in #9822 durchgeführt wird. Der nächste Schritt wäre, das AcroForm-Wörterbuch auf zB Schriftarten zu analysieren und den Standard-Erscheinungsbild-Eintrag im Anmerkungs-Wörterbuch für alle Erscheinungsbild-Informationen zu analysieren. Dazu können wir wahrscheinlich den Evaluator verwenden, um die Informationen als Operatorliste zu erhalten, die einen asynchronen Annotationscode erforderte. Dann können wir die Druckbedienerlisten für jeden Anmerkungstyp erstellen.

Ich dachte auch daran, die Operationsliste selbst zu erstellen, aber das wäre für mich komplizierter als mein Ansatz. Ich erstelle einfach den pdf-Objektstream mit 'BMC ... EMC' und übergebe den Stream an den Evaluator, der die Operationsliste generiert.
Wenn ich das Operationslisten-Array selbst erstelle, habe ich die gleichen Probleme wie beim Generieren eines neuen Objektstroms. Aber imho ist es komplizierter, die Oplist zu erstellen, als einen String zu erstellen und ihn in einen Objectstream umzuwandeln. Dies funktioniert bereits in meinem Proof of Concept.

Obwohl Opera/Chrome auch pdf.js verwendet, kann Opera Formulardaten drucken und verwenden. Vielleicht gibt es etw. können wir wiederverwenden?

Sie verwenden PDFium, bei dem es sich hauptsächlich um C++-Code handelt.

Hallo zusammen, die Firma, für die ich arbeite, beginnt, PDFJS zu nutzen, und mir wurde gesagt, dass ich "Eingegebene Werte speichern, wenn die Seite zerstört wird, wenn sie nicht sichtbar ist" zum Laufen bringen muss. Ich bin mir nicht sicher, ob dieser Thread der richtige Ort ist, um darüber zu diskutieren. @timvandermeij , es sieht so aus, als ob Sie ein wichtiger Treiber dieses Projekts sind. Können wir uns trotzdem mit Ihnen oder jemandem aus der Community in Verbindung setzen, der Ihnen helfen könnte. Ich habe eine Strategie für die Implementierung dieser Funktion, möchte jedoch sicherstellen, dass das, was ich tue, auch in dieses Repository übernommen werden kann. Wir sind auch bereit, einige Feature-Bounty zu sponsern oder zu erstellen, wenn dies dazu beitragen würde, die Dinge schneller zu erledigen.

Wenn Sie Ideen haben, wie dies geschehen soll, öffnen Sie am besten ein separates Thema, um dies zu besprechen. Die Hauptfrage ist, was mit den eingegebenen Daten geschehen soll. Beim Drucken auf die Leinwand rendern? Bieten Sie eine Option zum Herunterladen der Werte im FDF-Format an? Eine neue PDF-Datei mit den gefüllten Werten rendern? Und so weiter. Es hängt davon ab, was der Benutzer erwartet und was andere PDF-Reader tun.

Wird geschlossen, da die AcroForm-Unterstützung nun abgeschlossen und aktiviert ist. Die restlichen Ausgaben werden nun in Einzelausgaben abgelegt und mit dem Tag 4-form-acroform gesammelt; siehe https://github.com/mozilla/pdf.js/labels/4-form-acroform.