Ein gewöhnlicher Testname funktioniert. Bei deinem tatsächlichen Namen bricht das Speichern ab, oder nach dem erneuten Öffnen fehlen Zeichen. Prüfe zuerst, ob überhaupt eine ausgefüllte Datei erzeugt wurde. Ein Serverfehler beim Speichern und eine fehlerhafte Anzeige einer gespeicherten Datei sind unterschiedliche Ausgangspunkte.
Ein konkreter Stirling-PDF-Bericht beschreibt für die Docker-Versionen 3.1.0 und 3.2.0 einen Fehler beim Füllen von Helvetica-Formularfeldern. Thai, kyrillische und chinesische Testwerte führen dort laut Meldendem zu HTTP 500; ein lateinischer Kontrollwert funktioniert. Im Protokoll erscheinen Hinweise auf Helvetica und WinAnsiEncoding. Das ist ein belegter Bericht, keine Aussage über jede PDF-Datei oder jede Softwareversion. Q1
Welches Fehlerbild liegt bei dir vor?
Ordne deinen Fall möglichst einer dieser Beobachtungen zu:
| Beobachtung | Sinnvoller nächster Prüfschritt |
|---|---|
| Speichern endet mit HTTP 500; keine neue PDF vorhanden | Version, Feldname und Fehlermeldung sichern |
| Eine neue PDF entsteht; einzelne Zeichen fehlen | Gespeicherte Datei erneut öffnen und Anzeige vergleichen |
| Eine Anzeige funktioniert, eine andere nicht | Dieselbe unveränderte Datei mit den tatsächlich verwendeten Programmen vergleichen |
| Zeichen sind vorhanden, aber ungewohnt verbunden oder angeordnet | Darstellung anhand der korrekten Schreibweise beurteilen lassen |
| Die Datei ist bereits unterschrieben oder lässt sich nicht bearbeiten | Signatur- und Bearbeitungsstatus vor einer Änderung klären |
Ein älterer Stirling-Bericht zeigt die zweite und dritte Variante: Chinesische und japanische Eingaben sind nach dem Speichern nicht überall sichtbar; der Autor beschreibt Unterschiede zwischen Chrome und Safari. Dieser Bericht ist kein Nachweis, dass jeder solche Anzeigeunterschied dieselbe Ursache hat. Q2
Warum ein zusätzlicher Font allein nicht ausreichen muss
Prüfe Zeichenvorrat, verwendeten Kodierungspfad und richtige Darstellung getrennt. Die PDFBox-Dokumentation unterscheidet Kodierungsfehler von der Unterstützung komplexer Schriftsysteme. Eine gefundene Schriftdatei beantwortet diese Fragen noch nicht. Q3
Außerdem muss das betroffene Formularfeld die geeignete Schrift tatsächlich verwenden. Im geprüften Stirling-Quellstand v3.1.0 versucht die untersuchte Fehlerbehandlung erneut eine Helvetica-Schrift. Daraus folgt: Eine andere verfügbare Schriftdatei allein belegt noch keine passende Zuweisung für dieses Feld. Q5
Für dich ist deshalb die konkrete Datei entscheidend: ein bestimmtes Feld, sein tatsächlicher Text und die daraus erzeugte Ausgabe.
Ersthilfe: Ein kleiner Test, der den Fehler eingrenzt
1. Bewahre das Original auf. Erzeuge eine Arbeitskopie. Notiere, woher die Vorlage stammt und ob sie nach dem Ausfüllen weiter bearbeitbar bleiben muss. Verwende für die erste Diagnose möglichst eine unkritische Testvorlage mit demselben Fehlerbild.
2. Kläre den Formulartyp. PDF-Formulare können Feldwerte und ihre sichtbare Darstellung in unterschiedlichen Strukturen verwalten. Daneben kann eine XFA-Struktur enthalten sein. Die pypdf-Dokumentation beschreibt diese Unterschiede ausdrücklich. Ein Befund zu AcroForm-Feldern sollte deshalb nicht ungeprüft auf XFA übertragen werden. Q4
Wenn dein Werkzeug keine passenden Felder findet, halte an dieser Stelle an. Ein neues Schriftpaket ist noch keine Erklärung dafür, weshalb die Feldstruktur nicht erkannt wird. Bitte gegebenenfalls den Ersteller um eine passende bearbeitbare Vorlage.
3. Prüfe ein einzelnes Feld zweimal. Fülle in je einer frischen Kopie zunächst einen einfachen Kontrollwert ein und anschließend einen kurzen Wert mit den betroffenen Zeichen. Verwende dasselbe Feld und denselben Ablauf. Notiere, ob der Fehler schon bei der Eingabe, beim Speichern oder erst beim erneuten Öffnen sichtbar wird.
4. Sichere die genaue Fehlermeldung. Bei einem Serverfehler sind Zeitpunkt, Stirling-Version, Feldname und ein kleiner Logausschnitt hilfreich. Ein Hinweis wie U+0E19 benennt ein konkretes Zeichen; Helvetica und WinAnsiEncoding geben im untersuchten Bericht einen engeren Prüfpfad vor als die allgemeine Aussage „Unicode geht nicht“. Q1
5. Prüfe die gespeicherte Datei neu. Wenn eine Datei erzeugt wurde, schließe die erste Ansicht und öffne genau diese Ausgabe erneut. Vergleiche anschließend mit dem Programm, in dem der Empfänger tatsächlich arbeitet. Notiere für jede Ansicht, was sichtbar ist. So vermischst du eine erfolgreiche Vorschau nicht mit einem erfolgreichen Austausch der Datei.
6. Prüfe den fachlichen Inhalt. Vergleiche die vollständige Schreibweise einschließlich Zusatzzeichen, Abstände und Reihenfolge. Bei einer dir unbekannten Schrift sollte eine Person, die sie lesen kann, das Ergebnis beurteilen. Ein Bild kann plausibel aussehen und trotzdem den Namen falsch wiedergeben. Falls Kopieren oder automatische Weiterverarbeitung zum Ablauf gehört, prüfe auch dieses Ergebnis separat.
Welche Behebung passt zu welchem Befund?
Für einen nachgewiesenen Schrift- oder Kodierungsfehler sollte die Korrektur am verwendeten Feld und an der Erzeugung seiner Ausgabe ansetzen. Für eine bereits erzeugte Datei mit abweichender Anzeige braucht es einen Vergleich der Feldwerte und ihrer sichtbaren Darstellung. Bei einem anderen Formulartyp oder einer Bearbeitungsbeschränkung muss dieser Befund zuerst geklärt werden.
Wähle anschließend eine kleine, überprüfbare Änderung: etwa eine korrigierte Vorlage, eine nachweislich passende Schriftzuweisung oder eine vom Hersteller dokumentierte Änderung des eingesetzten Verarbeitungspfads. Prüfe danach dieselben Testwerte erneut. Eine installierte Schrift, ein erfolgreicher Neustart oder ein grüner Speicherdialog sind jeweils nur Zwischenergebnisse.
Verändere einen Personennamen nicht stillschweigend in eine andere Schreibweise, um den technischen Fehler zu verdecken. Falls ein Prozess eine Umschrift vorsieht, muss diese fachliche Entscheidung getrennt getroffen werden.
Bereits unterschrieben? Zuerst den vorgesehenen Ablauf klären
Adobe beschreibt, dass digitale Signaturen die weitere Bearbeitung einschränken können. Für Änderungen kann eine ursprüngliche, nicht unterschriebene Fassung erforderlich sein. Deshalb sollte eine Schriftreparatur nicht versehentlich an die Stelle einer Signaturprüfung treten. Bewahre die unterschriebene Datei unverändert auf und kläre, welche Änderungen im vorgesehenen Ablauf zulässig sind. Q6
Ob das Dokument bereits unterschrieben ist, ob eine Signatur gültig ist und ob weitere Formularänderungen zulässig sind, sind getrennte Fragen. Eine einfache Dateianalyse sollte diese nicht mit einem einzigen „alles in Ordnung“ beantworten.
Wann ist das Ergebnis brauchbar?
Vereinbare die Abnahme anhand deines tatsächlichen Ablaufs. Der problematische Name lässt sich speichern. Die erzeugte Datei kann erneut geöffnet werden. Die Schrift wird im Zielprogramm richtig dargestellt. Die vollständige Schreibweise bleibt erhalten.
Wenn das Formular weiter bearbeitbar sein muss, gehört ein weiterer zulässiger Bearbeitungsschritt zur Prüfung. Wenn es gedruckt, kopiert oder maschinell ausgelesen wird, prüfe genau diese zusätzliche Verwendung. Halte Vorlage, Softwarestand, Testwert und Ergebnis zusammen fest. Diese Abnahme bestätigt die geprüften Kombinationen, keine Unterstützung sämtlicher Sprachen.
Häufige Fragen
Die passende Schrift ist bereits im Container. Warum scheitert das Feld trotzdem?
Verfügbarkeit und tatsächliche Verwendung sind verschiedene Fragen. Der untersuchte Stirling-Quellstand zeigt einen erneuten Helvetica-Versuch in der Fehlerbehandlung. Prüfe deshalb die Schriftzuordnung des betroffenen Felds. Q5
Hilft es, die Eingabedatei einfach als UTF-8 zu speichern?
Das belegt noch keine passende PDF-Schriftkodierung. Prüfe anhand der WinAnsi-Meldung das konkrete Zeichen und den verwendeten Schriftpfad. Q3
In einem anderen Browser sieht der Name richtig aus. Ist die Datei damit repariert?
Das ist ein hilfreicher Vergleichsbefund. Prüfe weiterhin das Zielprogramm und die gespeicherte Datei. Im älteren Stirling-Bericht traten gerade unterschiedliche Anzeigeergebnisse auf. Q2
Soll ich das Formular in eine nicht mehr bearbeitbare PDF umwandeln?
Nur wenn das zum vorgesehenen Ablauf passt. Beim sogenannten Flattening werden Feldinhalte in normalen Seiteninhalt überführt und die eigentlichen Formularfelder entfernt. Es verändert damit die weitere Bearbeitbarkeit. Prüfe die gewünschte Ausgabe, bevor du diesen Weg wählst. Q4
Reicht irgendeine große Unicode-Schrift für alle Sprachen?
Eine solche Pauschalzusage ist nicht begründet. Prüfe die konkreten Testwerte einschließlich ihrer richtigen Darstellung. Q3
Löst ein Update das Problem automatisch?
Für die hier untersuchte Meldung ist keine bestimmte behobene Stirling-Version nachgewiesen. Halte den installierten Stand fest und prüfe eine dokumentierte Korrektur mit der problematischen Vorlage. Ein Versionswechsel allein ist keine Abnahme.
Beschreibe deinen Fall
Nenne Stirling-Version und Installationsart, den betroffenen Arbeitsschritt, den Feldnamen und das Verhalten beim Speichern. Ergänze den Fehlertext sowie einen kurzen unkritischen Testwert mit denselben Zeichenarten. Hilfreich sind außerdem der Formulartyp, das Zielprogramm und die Information, ob die Datei bereits digital unterschrieben ist.
Befundnotiz vorbereiten
Fasse deine Beobachtungen für die Anfrage zusammen. Die Notiz entsteht in deinem Browser; sie wird hier weder gespeichert noch versendet. Du kannst sie anschließend ins Kontaktformular kopieren.
Unbekannt ist möglich. Bitte keine Passwörter, Kundendaten oder vollständigen vertraulichen Protokolle eintragen.
Unterstützung bei diesem Fehler
Wir können Formular, Schrift und PDF-Verarbeitung mit einem bereinigten Beispiel untersuchen und den betroffenen Verarbeitungsschritt bestimmen.
Quellen
- [Q1] Stirling PDF Issue8576: Form-fill mit Helvetica
- [Q2] Stirling PDF Issue4102: fehlende Zeichen nach Speichern
- [Q3] Apache PDFBox3.0 FAQ
- [Q4] pypdf: Interactions with PDF Forms
- [Q5] Stirling FormUtils.java v3.1.0
- [Q6] Adobe: Permissions and limitations of signed PDFs
Quellenstand: 4. November 2026.
