PDF-Local-Storage: improvisierte interne Datenbank für Acrobat-Formulare

Die Grundidee: PDF-Local-Storage als Ersatz für das Global-Objekt

• Ablage im PDF selbst
• kommt ohne sichtbare Felder aus
• in vielen Viewern lauffähig
• Acrobat Pro nicht erforderlich
• nimmt Zustände auf
• nimmt Katalogdaten auf
• Speicherformat: JSON
• Kombination mehrerer Felder möglich
• Zugriff über Funktionen, nicht direkt

Auf dieser Basis lässt sich auch komplexere Formularlogik verlässlich aufbauen. Übersetzungen, Textbausteine, Maschinenlisten oder vorübergehende Zustände stehen im Dokument selbst bereit; verarbeiten lassen sie sich, ohne auf externe Dateien oder gelockerte Sicherheitseinstellungen angewiesen zu sein.

Global-Objekt in PDF-Formularen: warum es sich in der Praxis kaum nutzen lässt

Technisch betrachtet ist das Global-Objekt reizvoll: Es benimmt sich wie ein gewöhnliches JavaScript-Objekt und kann Daten unmittelbar in der Formularlogik vorhalten. Im Alltag hängt sein Einsatz jedoch davon ab, ob der Viewer es unterstützt – und genau daran scheitert er. Wird ein Formular außerhalb von Adobe Acrobat Pro geöffnet, versagt diese Art der Speicherung häufig komplett.

• Kompatibilität nur sehr begrenzt: Die Funktion setzt eine kostenpflichtige Acrobat-Umgebung voraus; zahlreiche kostenlose oder alternative PDF-Viewer bieten sie nicht an.
• Unsichere Grundlage für die Verteilung: Baut ein Formular auf Global auf, läuft es nur dort einwandfrei, wo die passende Software samt Lizenz installiert ist.
• Im Alltag wenig tauglich: Schon der Umstieg vom Bürorechner auf den privaten Rechner kann die komplette Speicherlogik außer Kraft setzen.
• Viel Aufwand im Support: Die Ursache der Fehler liegt nicht in der Formularlogik, sondern in den unterschiedlichen Viewern und Installationen.
• Kaum skalierbar: Sobald externe Nutzer, Mobilgeräte oder wechselnde Arbeitsplätze ins Spiel kommen, lässt sich der Ansatz kaum noch kontrollieren.
• Technisch stark, im Betrieb schwach: In der Theorie ist der Nutzen groß, in der Praxis reicht der Ansatz aber nicht weit genug.

Aus diesen Gründen taugt Global für weit verbreitete PDF-Formulare meist nicht als Fundament. Sollen Formulare überall funktionieren, ist ein interner Speicher nötig, der von keiner einzelnen Viewer-Klasse abhängt.

Interner Speicher im PDF: So arbeiten die versteckten Felder

• Das Formular bekommt ein oder mehrere zusätzliche Felder, die nicht der normalen Eingabe dienen, sondern allein interne Daten speichern.
• Sie fallen winzig aus – beispielsweise rund 1 mal 1 Millimeter –, sodass sie im Layout praktisch nicht in Erscheinung treten.
• Außerdem sind die Felder gesperrt: So kann niemand sie aus Versehen aktivieren, markieren oder überschreiben.
• Ein weißer Hintergrund senkt zusätzlich die Gefahr, dass das Feld ins Auge fällt – auch für den theoretischen Fall, dass es doch angesteuert wird.
• Ihren Platz finden die Felder am Rand oder in den Ecken des Formulars, wo die Maus im normalen Gebrauch kaum hinkommt.
• Abgelegt wird nicht ein einzelnes, loses Attribut, sondern der gesamte Zustand in serialisierter Form – in der Regel als JSON-String.
• Das JavaScript des Formulars holt die Inhalte aus den Feldern, interpretiert sie und erzeugt daraus erneut die Datenstrukturen, mit denen die Anwendung arbeitet.
• Nutzer sehen von diesem Speicher nichts; der Formularlogik steht er im PDF trotzdem dauerhaft zur Verfügung.
• Das Ergebnis ist eine interne Speicherschicht, die weder externe Dateien noch eine Datenbankverbindung noch das proprietäre Global-Objekt benötigt.

Set, Get, Remove und Reset: So ist die Formilo-Bibliothek aufgebaut

Jeder Zugriff auf den internen PDF-Storage läuft vollständig über die Formilo-Bibliothek. Die Formularlogik muss sich deshalb weder um Feldinhalte noch um String-Verkettungen oder die JSON-Verarbeitung kümmern – sie ruft eindeutig definierte Funktionen auf, deren Schnittstelle stabil bleibt.

• Set
• Get
• Remove
• Reset
• Parameter: Schlüssel
• Parameter: Wert
• Daten an einer zentralen Stelle
• JSON-Logik gekapselt
• Fehlerbehandlung nach einheitlichem Muster

Durch diese Abstraktion wird der Speicher im täglichen Einsatz spürbar robuster. Wer das Formular entwickelt, hantiert mit fachlichen Schlüsseln und Werten statt mit den technischen Einzelheiten der Ablage. So gibt es weniger Fehlerquellen, die Wartung wird einfacher, und die interne Speicherlogik kann später wachsen, ohne dass der restliche Formularcode grundlegend umgebaut werden muss.

JSON, Arrays, Objekte, Verschachtelungen: das Datenmodell im PDF-Storage

Grundlage des internen PDF-Storages ist ein strukturiertes Datenmodell, das auf JSON aufbaut. Es nimmt deshalb neben einfachen Einzelwerten auch komplexe Zusammenhänge auf, wie sie Formulare häufig für ihre Logik, für Auswahlhilfen oder die Statusverwaltung brauchen. Der Kern: Die Daten werden nicht Feld für Feld betrachtet, sondern als eine zusammenhängende Objektstruktur.

• Primitive Werte: Texte, Zahlen, Wahrheitswerte oder leere Zustände können unmittelbar Teil des JSON-Modells werden.
• Speicherung als Objekt: Jeder Eintrag lässt sich als Objekt anlegen – mit eindeutigen Schlüsseln und sauberer Zuordnung.
• Listen als Arrays: Kataloge, Datensammlungen oder mehrere Auswahlwerte liegen als geordnete Listen vor.
• Freie Verschachtelung: Arrays dürfen Objekte enthalten und Objekte wiederum Arrays – Voraussetzung ist nur, dass sich die Struktur serialisieren lässt.
• Sauber serialisiert: Eigene Typen werden vor dem Speichern in eine übertragbare Form gebracht und beim Einlesen zurückübersetzt.
• Ein gemeinsamer Gesamtzustand: Der maßgebliche Zustand der Anwendung ist nicht über Einzellogik verstreut, sondern in einer konsistenten Datenbasis gebündelt.

In dieser Flexibilität liegt die eigentliche Stärke des Ansatzes. Der Storage ist mehr als eine Notlösung für einzelne Werte: Auf ihm lassen sich komplexere PDF-Anwendungen aufbauen, die ihre Zustände und Daten intern verwalten.

Warum der PDF-Storage mehr als ein Speicherfeld braucht

• Sollen auch Kataloge, Zustände oder Übersetzungen hinein, erreicht ein einzelnes Feld rasch seine technische Längengrenze.
• Bereits eine Handvoll strukturierter Datensätze ergibt serialisierte JSON-Strings, die weit länger ausfallen als gewöhnliche Formularwerte.
• Nimmt der Datenbestand weiter zu, läuft das Speichern unzuverlässig oder scheitert ganz, weil die Kapazität des Feldes nicht reicht.
• Künftige Erweiterungen der Formularlogik kann ein einzelnes Speicherfeld ebenfalls kaum sauber auffangen.
• Hinzu kommt ein Engpass: Gibt es nur ein Feld, berührt jede Änderung dessen gesamten Inhalt.
• Das erhöht die Gefahr, dass Aktualisierungen bei großen Datenmengen fehleranfälliger oder unhandlich werden.
• Mit mehreren Feldern verteilt sich die Last, die nutzbare Kapazität steigt, und die Speicherung lässt sich besser planen.
• Für PDF-Anwendungen im produktiven Einsatz ist der Mehrfeldansatz darum die klar tragfähigere Architektur.

Mehrere Felder lesen und beschreiben: Chunks, Konkatenation, JSON-Decode

Im Mehrfeldansatz gilt der interne Speicher als ein zusammenhängender Datenstrom und nicht als einzelner, isolierter Feldwert. Beim Einlesen werden alle vorgesehenen Felder der Reihe nach ausgelesen; ihre Inhalte werden in festgelegter Reihenfolge aneinandergefügt, und erst das Ergebnis wird als vollständiger JSON-String interpretiert. Aus vielen kleinen Speichersegmenten wird so wieder ein stimmiger Gesamtzustand.

• sämtliche Speicherfelder auslesen
• feste Reihenfolge beachten
• Teilstrings aneinanderfügen
• JSON komplett dekodieren
• Datenstruktur im Speicher anpassen
• erneut serialisieren
• String in Chunks zerlegen
• Chunks den Feldern zuweisen
• Überlauf kontrolliert behandeln

Das Speichern geht den umgekehrten Weg: Der vorhandene Gesamtinhalt wird geladen, fachlich angepasst, danach neu serialisiert und erneut auf mehrere Felder aufgeteilt. Für die Formularlogik bleibt die Schnittstelle dadurch schlicht – auch wenn im Hintergrund segmentiert gespeichert wird.

Wenn der Speicher an seine Grenzen stößt: Fehlerfälle und klare Rückmeldungen der Bibliothek

Im praktischen Einsatz bewährt sich ein interner PDF-Storage nur, wenn er Grenzen und Fehler offenlegt, statt sie stillschweigend zu übergehen. Gerade bei serialisierten Datenstrukturen kann an mehreren Stellen etwas schiefgehen – beim Einlesen, beim Dekodieren, beim Ändern der Daten oder beim Zurückschreiben in die vorgesehenen Felder. Speichern allein genügt deshalb nicht: Die Bibliothek muss verlässlich prüfen und eindeutig mitteilen, was im Moment geht und was nicht.

• Kapazität erschöpft: Genügt der Platz in allen Speicherfeldern zusammen nicht, muss die Bibliothek das Schreiben abbrechen, anstatt die Daten nur teilweise zu verteilen.
• Ungültiges JSON: Ist der zusammengesetzte Inhalt defekt oder lückenhaft, darf nicht stillschweigend weitergearbeitet werden – sonst drohen Folgefehler.
• Felder fehlen: Sind erwartete Speicherfelder gelöscht, umbenannt oder falsch eingerichtet, muss die Bibliothek das bemerken.
• Reihenfolge durcheinander: Passen Feldreihenfolge oder Chunk-Zuordnung nicht mehr, lässt sich der Gesamtinhalt nicht mehr sauber wiederherstellen.
• Verständliche Meldungen: Entwickler wie Anwender müssen erkennen können, ob ein Speicherlimit erreicht ist, ein Strukturfehler vorliegt oder die Konfiguration nicht stimmt.
• Definierte Rückgabewerte: Die Funktionen sollten festgelegte Werte zurückgeben, damit die Formularlogik auf Fehler reagieren kann, anstatt unkontrolliert weiterzulaufen.

Klare Rückmeldungen gehören deshalb zum Kern der Architektur und sind keine Dreingabe. Erst sie machen aus einem versteckten Feldspeicher einen verlässlichen technischen Baustein für Formulare im produktiven Einsatz.

Was sinnvoll in den PDF-Local-Storage gehört

• Materialkataloge samt Bezeichnungen, Kurzinfos, internen Kennungen und weiteren Auswahlwerten für Formularvorgänge, die sich wiederholen.
• Maschinenkataloge oder Stammdaten von Geräten, auf die Eingaben, Prüfungen oder automatische Vorbelegungen zurückgreifen.
• Textbausteine mit Standardformulierungen, mit denen Nutzer längere Felder zügiger ausfüllen.
• Übersetzungen für Oberflächenbegriffe, Meldungen oder Hilfetexte, sodass mehrsprachige Formularlogik in ein und derselben Datei steckt.
• Feldzustände wie Zwischenergebnisse, Auswahlhistorien, Sichtbarkeiten oder aktivierte Prozessschritte.
• Paginierte Datensätze für den Fall, dass mehr Inhalte vorliegen, als die sichtbaren Formularfelder gleichzeitig anzeigen können.
• Vorübergehende Arbeitsdaten für Undo und Redo, mit denen sich einzelne Bearbeitungsschritte gezielt rückgängig machen oder wiederherstellen lassen.
• Nutzdaten für den Export, die später gebündelt an externe Systeme, in Dateien oder in manuelle Übergabeprozesse gehen.

PDF-Local-Storage im Einsatz: Kataloge, Übersetzungen, Zustände, Paginierung, Undo und Redo

Der eigentliche Nutzen von PDF-Local-Storage wird erst im laufenden Betrieb sichtbar. Soll ein Formular mehr leisten, als einzelne Feldwerte aufzunehmen, braucht es interne Daten, die auch ohne sichtbare Eingabefelder bereitstehen. Für genau diesen Zweck passt der Speicheransatz: Er hält die Informationen im Dokument selbst bereit und lässt komplexere Abläufe auch dann beherrschbar werden, wenn auf dem Formular nur wenig sichtbare Fläche zur Verfügung steht.

• Materialkataloge lokal bereitstellen
• Maschinenlisten ohne Umweg abrufen
• Textbausteine an einer Stelle sammeln
• Sprachwechsel intern regeln
• Feldzustände dauerhaft festhalten
• Zwischenschritte zuverlässig zwischenspeichern
• Datensätze Seite für Seite laden
• Undo-Verläufe intern speichern
• Redo gezielt anbieten

Seine Stärken spielt der Ansatz vor allem aus, wenn ein Formular viele Datensätze, aber wenig Platz pro Seite hat. In die sichtbaren Felder kommt dann jeweils nur, was gerade gebraucht wird; alles Übrige bleibt im internen Speicher. Die Funktionen, die so entstehen, wirken eher wie klassische Anwendungen als wie einfache PDF-Formulare.

Was PDF-Local-Storage externen Dateien, Datenbankanbindungen und dem Acrobat-Pro-Global voraushat

Den Reiz von PDF-Local-Storage macht vor allem aus, dass er die Stärken interner Datenhaltung mit hoher Praxistauglichkeit zusammenbringt. Anders als das Global-Objekt ist die Lösung nicht auf Acrobat Pro angewiesen. Anders als externe Dateien oder Datenbankzugriffe hält sie den kompletten Datenbestand im Dokument. Der Integrationsaufwand fällt dadurch geringer aus, und viele der üblichen Hürden bei Berechtigungen, Dateizugriffen und Viewer-Unterschieden gibt es gar nicht erst.

• Läuft in mehr Viewern: Die Speicherung klappt in erheblich mehr PDF-Viewern als das proprietäre Global-Objekt und passt deshalb besser zu den Umgebungen, in die Formulare tatsächlich verteilt werden.
• Ohne externe Infrastruktur: Um Hilfsdaten innerhalb des Formulars bereitzustellen, braucht es weder Server noch Datenbank.
• Weniger Konflikte mit Sicherheitseinstellungen: Da die Daten im Formular verbleiben, entfallen zusätzliche Dateizugriffe, denen Sicherheitseinstellungen häufig einen Riegel vorschieben.
• Offline nutzbar: Auch ohne Verbindung zu einem externen System können die Formulare mit den nötigen Hilfs- und Zustandsdaten arbeiten.
• Freie Datenstrukturen: Im Gegensatz zu einem rein feldgebundenen Export können auch komplexe, frei modellierte Informationen verwaltet werden.
• Verlässlich im Betrieb: Weil er weniger von den Voraussetzungen fremder Systeme abhängt, lässt sich der Ansatz in produktiven Formularen besser beherrschen.

Der interne Speicher ist damit vielseitiger einsetzbar und im Betrieb belastbarer als viele Alternativen, die auf den ersten Blick näherliegen.

Den internen PDF-Storage exportieren – mit und ohne gelockerte Sicherheitseinstellungen

• Erlauben die Sicherheitsvorgaben des Viewers oder der Umgebung entsprechende Schreib- oder Übertragungsvorgänge, kann der Export der gespeicherten Daten automatisch ablaufen.
• Dann lässt sich der serialisierte Inhalt des internen Storages als JSON oder in einer anderen passenden Struktur an ein externes System weiterreichen.
• Auch eine Datenbank kommt als Empfänger infrage, sofern die Formularumgebung so eingestellt ist, dass sie externe Kommunikation zulässt.
• Wo die Sicherheitseinstellungen streng sind und nicht gelockert werden, bietet das Formular selbst einen manuellen, dafür robusten Ausweg.
• Vorgesehen ist dafür ein größeres, mehrzeiliges Textfeld, das den serialisierten Storage-Inhalt vollständig aufnehmen kann.
• Der Nutzer kann den Inhalt dort direkt markieren, kopieren und eigenhändig in eine Datei oder ein Zielsystem übernehmen.
• Viel Mehraufwand entsteht dabei nicht: Es braucht nur wenige Handgriffe und keine technische Sonderfreigabe.
• Anders als ein klassischer FDF-Export bleibt diese Methode nicht auf sichtbare Formularfelder und ihre Struktur begrenzt.
• So lassen sich auch frei definierte Datenmodelle ausgeben, zum Beispiel Kataloge, Zustände, Historien oder sonstige interne Arbeitsdaten.

Häufige Fragen

Fazit

Mit PDF-Local-Storage rücken interaktive PDF-Formulare nah an Software heran: Strukturierte Daten liegen im Dokument selbst, das Formular läuft in vielen Viewern, und weder Acrobat Pro noch externe Infrastruktur sind Pflicht. So lassen sich Kataloge, Zustände und komplexere Logik auch innerhalb eines PDFs beherrschen.

Sie planen ein PDF-Formular mit interner Datenhaltung und möchten es umsetzen lassen?