Improvisierte interne Datenbank in Acrobat Formularen

PDF-Local-Storage statt Global-Objekt: die Grundidee

• direkt im PDF gespeichert
• ohne sichtbare Eingabeflächen
• breit in Viewern nutzbar
• kein Acrobat-Pro-Zwang
• geeignet für Zustände
• geeignet für Katalogdaten
• JSON als Speicherformat
• mehrere Felder kombinierbar
• Funktionen statt Direktzugriff

Damit entsteht eine belastbare Grundlage für komplexere Formularlogik. Inhalte wie Übersetzungen, Textbausteine, Maschinenlisten oder temporäre Zustände bleiben innerhalb des Dokuments verfügbar und können unabhängig von externen Dateien oder gelockerten Sicherheitseinstellungen verarbeitet werden.

Warum das Global-Objekt in PDF-Formularen praktisch kaum einsetzbar ist

Das Global-Objekt ist technisch attraktiv, weil es sich wie ein normales JavaScript-Objekt verhält und Daten direkt innerhalb der Formularlogik halten kann. In der Praxis scheitert sein Einsatz aber an der Unterstützung durch die Viewer. Sobald ein Formular ausserhalb von Adobe Acrobat Pro verwendet wird, fällt diese Speichertechnik oft vollständig aus.

• Stark eingeschränkte Kompatibilität: Die Funktion ist an eine kostenpflichtige Acrobat-Umgebung gebunden und steht in vielen kostenlosen oder alternativen PDF-Viewern nicht zur Verfügung.
• Keine verlässliche Basis für Verteilung: Ein Formular, das auf Global aufbaut, funktioniert nur dort sauber, wo die passende Lizenz und Software vorhanden sind.
• Schwache Alltagstauglichkeit: Bereits der Wechsel vom Bürorechner auf einen privaten Rechner kann die gesamte Speicherlogik unbrauchbar machen.
• Hoher Supportaufwand: Fehler entstehen nicht durch die Formularlogik selbst, sondern durch unterschiedliche Viewer und Installationen.
• Schlechte Skalierbarkeit: Für externe Nutzer, mobile Geräte oder wechselnde Arbeitsplätze ist der Ansatz kaum kontrollierbar.
• Technisch gut, operativ schwach: Der Nutzen bleibt theoretisch hoch, praktisch ist die Reichweite aber zu klein.

Genau deshalb ist Global für breit eingesetzte PDF-Formulare meist keine tragfähige Grundlage. Wer Formulare universell nutzbar machen will, braucht einen internen Speicher, der nicht an eine einzelne Viewer-Klasse gekoppelt ist.

Wie versteckte Felder als interner Speicher im PDF funktionieren

• Im Formular werden ein oder mehrere zusätzliche Felder angelegt, die nicht für normale Eingaben gedacht sind, sondern ausschliesslich interne Daten aufnehmen.
• Diese Felder werden extrem klein dimensioniert, zum Beispiel etwa 1 mal 1 Millimeter, damit sie im Layout faktisch keine sichtbare Rolle spielen.
• Zusätzlich werden die Felder gesperrt, damit Benutzer sie nicht versehentlich aktivieren, überschreiben oder markieren können.
• Eine weisse Hintergrundfarbe reduziert das Risiko weiter, dass das Feld optisch auffällt, selbst wenn es theoretisch angesteuert werden könnte.
• Die Platzierung erfolgt in Randbereichen oder Ecken des Formulars, also dort, wo normale Mausbewegungen kaum stattfinden.
• Gespeichert wird kein loses Einzelattribut, sondern ein serialisierter Gesamtzustand, typischerweise als JSON-String.
• Die JavaScript-Logik des Formulars liest diese Feldinhalte aus, interpretiert sie und stellt daraus wieder Datenstrukturen für die Anwendung her.
• Für den Benutzer bleibt der Speicher unsichtbar, für die Formularlogik ist er dennoch dauerhaft innerhalb des PDFs verfügbar.
• Damit entsteht eine interne Speicherschicht, die ohne externe Dateien, ohne Datenbankverbindung und ohne proprietäres Global-Objekt auskommt.

Aufbau der Formilo-Bibliothek für Set, Get, Remove und Reset

Die Formilo-Bibliothek kapselt den Zugriff auf den internen PDF-Storage vollständig, damit die Formularlogik nicht direkt mit Feldinhalten, String-Verkettungen oder JSON-Verarbeitung arbeiten muss. Stattdessen erfolgt jeder Zugriff über klar definierte Funktionen mit stabiler Schnittstelle.

• Set
• Get
• Remove
• Reset
• Schlüssel als Parameter
• Wert als Parameter
• zentrale Datenhaltung
• gekapselte JSON-Logik
• einheitliches Fehlermanagement

Diese Abstraktion macht den Speicher im Alltag deutlich robuster. Entwickler arbeiten mit fachlichen Schlüsseln und Werten, nicht mit technischen Details der Ablage. Das senkt Fehlerquellen, vereinfacht Wartung und erlaubt es, die interne Speicherlogik später zu erweitern, ohne den übrigen Formularcode grundlegend umzubauen.

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

Der interne PDF-Storage arbeitet mit einem strukturierten Datenmodell auf JSON-Basis. Dadurch lassen sich nicht nur einfache Einzelwerte speichern, sondern auch komplexe Zusammenhänge, die in Formularen oft für Logik, Auswahlhilfen oder Statusverwaltung benötigt werden. Entscheidend ist, dass die Daten nicht feldweise gedacht werden, sondern als zusammenhängende Objektstruktur.

• Primitive Werte: Texte, Zahlen, Wahrheitswerte oder leere Zustände lassen sich direkt als Teil des JSON-Modells ablegen.
• Objektbasierte Speicherung: Jeder Eintrag kann als Objekt geführt werden, was klare Schlüssel und saubere Zuordnung ermöglicht.
• Arrays für Listen: Kataloge, Datensammlungen oder mehrere Auswahlwerte können als geordnete Listen gespeichert werden.
• Beliebige Verschachtelung: Objekte in Arrays und Arrays in Objekten sind möglich, solange die Struktur serialisierbar bleibt.
• Saubere Serialisierung: Eigene Typen werden vor dem Speichern in eine übertragbare Struktur umgewandelt und beim Lesen wieder interpretiert.
• Einheitlicher Gesamtzustand: Statt verteilter Einzellogik liegt der relevante Anwendungszustand gesammelt in einer konsistenten Datenbasis vor.

Genau diese Flexibilität macht den Ansatz so stark. Der Storage ist nicht nur ein Notbehelf für Einzelwerte, sondern eine echte Grundlage für komplexere PDF-Anwendungen mit interner Zustands- und Datenverwaltung.

Warum ein einzelnes Speicherfeld nicht ausreicht

• Ein einzelnes Feld stösst schnell an technische Längenbegrenzungen, sobald Kataloge, Zustände oder Übersetzungen mitgespeichert werden sollen.
• Schon wenige strukturierte Datensätze erzeugen serialisierte JSON-Strings, die deutlich länger sind als einfache Formularwerte.
• Wächst der Datenbestand weiter, wird das Speichern instabil oder scheitert vollständig an der verfügbaren Feldkapazität.
• Auch spätere Erweiterungen der Formularlogik lassen sich mit nur einem Speicherfeld kaum sauber abfangen.
• Ein einziges Feld schafft ausserdem einen Engpass, weil jede Änderung den kompletten Inhalt dieses Feldes betrifft.
• Dadurch steigt das Risiko, dass grosse Datenmengen bei Aktualisierungen fehleranfälliger oder unpraktisch werden.
• Mehrere Felder verteilen die Last, erhöhen die nutzbare Kapazität und machen die Speicherung planbarer.
• Deshalb ist ein Mehrfeldansatz für produktive PDF-Anwendungen die deutlich belastbarere Architektur.

Lesen und Schreiben über mehrere Felder: Chunks, Konkatenation und JSON-Decode

Beim Mehrfeldansatz wird der interne Speicher nicht als isolierter Feldwert behandelt, sondern als zusammenhängender Datenstrom. Alle dafür vorgesehenen Felder werden beim Einlesen nacheinander ausgelesen, ihre Inhalte werden in definierter Reihenfolge zusammengefügt und erst danach als vollständiger JSON-String interpretiert. So entsteht aus mehreren kleinen Speichersegmenten wieder ein konsistenter Gesamtzustand.

• alle Speicherfelder lesen
• Reihenfolge strikt einhalten
• Teilstrings zusammenführen
• JSON vollständig dekodieren
• Datenstruktur im Speicher ändern
• neu serialisieren
• String in Chunks teilen
• Chunks auf Felder verteilen
• Überlauf sauber abfangen

Beim Speichern läuft der Prozess in umgekehrter Richtung. Zuerst wird der bestehende Gesamtinhalt geladen, dann fachlich verändert, anschliessend erneut serialisiert und wieder auf mehrere Felder verteilt. Dieses Vorgehen hält die Schnittstelle für die Formularlogik einfach, obwohl intern eine segmentierte Speicherung stattfindet.

Speichergrenzen, Fehlerfälle und saubere Rückmeldungen der Bibliothek

Ein interner PDF-Storage ist nur dann praxistauglich, wenn Grenzen und Fehler nicht stillschweigend übergangen werden. Gerade bei serialisierten Datenstrukturen können Probleme an mehreren Stellen auftreten: beim Einlesen, beim Dekodieren, beim Verändern der Daten oder beim Zurückschreiben in die vorgesehenen Felder. Die Bibliothek muss deshalb nicht nur speichern, sondern auch zuverlässig prüfen und klar melden, was gerade möglich ist und was nicht.

• Kapazitätsgrenze: Reicht der verfügbare Platz über alle Speicherfelder hinweg nicht aus, muss die Bibliothek den Schreibvorgang abbrechen statt Daten unvollständig zu verteilen.
• Ungültiges JSON: Ist der zusammengesetzte Inhalt beschädigt oder unvollständig, darf kein stiller Weiterbetrieb erfolgen, weil sonst Folgefehler entstehen.
• Fehlende Felder: Werden erwartete Speicherfelder gelöscht, umbenannt oder falsch konfiguriert, muss die Bibliothek diesen Zustand erkennen.
• Inkonsistente Reihenfolge: Stimmen Feldreihenfolge oder Chunk-Zuordnung nicht mehr, ist eine saubere Rekonstruktion des Gesamtinhalts nicht mehr möglich.
• Klare Fehlermeldungen: Entwickler und Anwender brauchen verständliche Hinweise, ob ein Speicherlimit, ein Strukturfehler oder ein Konfigurationsproblem vorliegt.
• Kontrollierte Rückgabe: Funktionen sollten definierte Rückgabewerte liefern, damit Formularlogik auf Fehler reagieren kann, statt unkontrolliert weiterzulaufen.

Saubere Rückmeldungen sind kein Zusatz, sondern ein Kernbestandteil der Architektur. Erst dadurch wird aus einem versteckten Feldspeicher eine belastbare technische Komponente für produktive Formulare.

Welche Daten sich im PDF-Local-Storage sinnvoll ablegen lassen

• Materialkataloge mit Bezeichnungen, Kurzinfos, internen Kennungen und weiteren Auswahlwerten für wiederkehrende Formularvorgänge.
• Maschinenkataloge oder Gerätestammdaten, die bei Eingaben, Prüfungen oder automatischen Vorbelegungen gebraucht werden.
• Textbausteine für standardisierte Formulierungen, die Benutzern das schnelle Ausfüllen längerer Felder erleichtern.
• Übersetzungen von Oberflächenbegriffen, Meldungen oder Hilfetexten für mehrsprachige Formularlogik innerhalb derselben Datei.
• Zustände von Formularfeldern, etwa Zwischenergebnisse, Auswahlhistorien, Sichtbarkeiten oder aktivierte Prozessschritte.
• Paginierte Datensätze, wenn mehr Inhalte vorhanden sind, als gleichzeitig in sichtbaren Formularfeldern dargestellt werden können.
• Temporäre Arbeitsdaten für Undo- und Redo-Funktionen, damit Bearbeitungsschritte gezielt zurückgesetzt oder wiederhergestellt werden können.
• Exportierbare Nutzdaten, die später gesammelt an externe Systeme, Dateien oder manuelle Übergabeprozesse übergeben werden.

Praktische Einsatzfälle: Kataloge, Übersetzungen, Zustände, Paginierung, Undo und Redo

Der eigentliche Mehrwert von PDF-Local-Storage zeigt sich im praktischen Betrieb. Sobald ein Formular mehr können soll als einzelne Feldwerte erfassen, braucht es interne Daten, die unabhängig von sichtbaren Eingabefeldern verfügbar bleiben. Genau dafür eignet sich dieser Speicheransatz. Er hält Informationen direkt im Dokument vor und macht komplexere Abläufe auch dann beherrschbar, wenn nur ein begrenzter sichtbarer Formularbereich vorhanden ist.

• Materialkataloge lokal vorhalten
• Maschinenlisten direkt verfügbar machen
• Textbausteine zentral speichern
• Sprachumschaltungen intern steuern
• Feldzustände dauerhaft merken
• Zwischenschritte sicher puffern
• Datensätze seitenweise laden
• Undo-Verläufe intern ablegen
• Redo-Funktionen gezielt ermöglichen

Besonders stark ist der Ansatz bei Formularen mit vielen Datensätzen und wenig Platz auf einer Seite. Dann können immer nur die gerade benötigten Inhalte in sichtbare Felder geladen werden. Der Rest bleibt im internen Speicher erhalten. So entstehen Funktionen, die eher an klassische Anwendungen erinnern als an einfache PDF-Formulare.

Vorteile gegenüber externen Dateien, Datenbankanbindungen und dem Acrobat-Pro-Global

PDF-Local-Storage ist vor allem deshalb interessant, weil er die Vorteile interner Datenhaltung mit hoher praktischer Verwendbarkeit verbindet. Im Unterschied zum Global-Objekt hängt die Lösung nicht an Acrobat Pro. Im Unterschied zu externen Dateien oder Datenbankzugriffen bleibt der gesamte Datenbestand innerhalb des Dokuments. Dadurch sinkt der Integrationsaufwand, und viele typische Hürden rund um Berechtigungen, Dateizugriffe und Viewer-Unterschiede entfallen.

• Breitere Kompatibilität: Die Speicherung funktioniert in deutlich mehr PDF-Viewern als das proprietäre Global-Objekt und eignet sich daher besser für reale Verteilumgebungen.
• Keine externe Infrastruktur: Es wird weder ein Server noch eine Datenbank benötigt, nur um formularinterne Hilfsdaten verfügbar zu machen.
• Weniger Sicherheitskonflikte: Weil die Daten im Formular bleiben, sind keine zusätzlichen Dateizugriffe erforderlich, die oft durch Sicherheitseinstellungen blockiert werden.
• Offline-Fähigkeit: Formulare können auch ohne Verbindung zu einem externen System mit relevanten Hilfs- und Zustandsdaten arbeiten.
• Flexible Datenstrukturen: Anders als bei rein feldgebundenem Export lassen sich auch komplexe, frei modellierte Informationen verwalten.
• Stabile Praxisnutzung: Der Ansatz ist für produktive Formulare besser kontrollierbar, weil er weniger von fremden Systemvoraussetzungen abhängt.

Damit wird der interne Speicher zu einer universelleren und betrieblich belastbareren Lösung als viele naheliegende Alternativen.

Export des internen PDF-Storages mit und ohne gelockerte Sicherheitseinstellungen

• Die gespeicherten Daten lassen sich automatisiert exportieren, wenn die Sicherheitsvorgaben des Viewers oder der Umgebung entsprechende Schreib- oder Übertragungsprozesse zulassen.
• In diesem Fall kann der serialisierte Inhalt des internen Storages als JSON oder in einer anderen geeigneten Struktur an ein externes System übergeben werden.
• Ebenso ist eine Übergabe an eine Datenbank denkbar, wenn die Formularumgebung so konfiguriert ist, dass externe Kommunikation erlaubt ist.
• Für strengere Umgebungen ohne gelockerte Sicherheitseinstellungen gibt es eine manuelle, aber robuste Alternative innerhalb des Formulars.
• Dafür wird ein grösseres mehrzeiliges Textfeld vorgesehen, in das der serialisierte Storage-Inhalt vollständig geschrieben werden kann.
• Der Benutzer kann diesen Inhalt direkt markieren, kopieren und selbst in eine Datei oder in ein Zielsystem übertragen.
• Der zusätzliche Aufwand ist gering, weil nur wenige manuelle Schritte nötig sind und keine technische Sonderfreigabe vorausgesetzt wird.
• Im Unterschied zu klassischen FDF-Exporten ist diese Methode nicht auf sichtbare Formularfelder und deren Struktur beschränkt.
• Dadurch können auch frei definierte Datenmodelle exportiert werden, etwa Kataloge, Zustände, Historien oder andere interne Arbeitsdaten.

Häufige Fragen

Fazit

PDF-Local-Storage macht interaktive PDF-Formulare softwareähnlich: strukturierte Daten direkt im Dokument, breite Viewer-Kompatibilität und kein Zwang zu Acrobat Pro oder externer Infrastruktur. Damit werden Kataloge, Zustände und komplexere Logik auch im PDF beherrschbar.

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