Änderungsprotokoll

Versionshistorie

Versionshistorie der PDFlibPas-Bibliothek. Die Einträge sind in absteigender Reihenfolge aufgelistet; jede Version folgt der Semantischen Versionierung gemäß der Veröffentlichungsrichtlinie des Projekts.

v3.56.42 2026-05-27

Der in v3.56.41 eingeführte pufferbasierte AES-256-Entschlüsselungspfad wurde korrigiert, sodass Aufrufer das Entschlüsselungsergebnis wieder derselben AnsiString-Variable zuweisen können, die den Ciphertext-Puffer bereitgestellt hat, ohne Zugriffsverletzungen auszulösen.
Der normale API-Ablauf LoadFromFile, Encrypt, SaveToFile, erneutes Laden, Decrypt und SaveToFile wird bei großen geladenen PDFs wieder abgeschlossen, während die AES-CBC-Entschlüsselungsoptimierung mit reduzierter Kopie erhalten bleibt.
Neue AES-Regressionsabdeckung prüft Eingabepuffer-/Rückgabeziel-Aliasfälle beim Rücksetzen verschlüsselter Streams während des Speicherns, einschließlich großer 504-KB-Nutzdaten, die den Fehler zuvor sichtbar machten.

v3.56.41 2026-05-27

TPDFlib.DACopyFile wurde für Direct Access Workflows ergänzt, die eine Seitenzahl und eine unveränderte Dateikopie benötigen, ohne den vollständigen normalen Objektgraphen aufzubauen.
Die AES-256-Entschlüsselung wurde durch pufferbasierte AES-CBC-Entschlüsselungspfade optimiert, die beim Entschlüsseln geladener Zeichenfolgen und Streams verwendet werden und zusätzliche Ciphertext-Kopien bei großen verschlüsselten Streams reduzieren.
Die Delphi HugeFileBenchmark Demo enthält jetzt eine direct-copy Zeile sowie --ops und --skip Filter für gezielte Großdatei-Läufe.

v3.56.40 2026-05-26

Die Delphi- und C++Builder-Demos HelloWorld erstellen jetzt ein umfangreicheres Start-PDF mit Dokumentinformationen, Ausgabe in einer ausgewählten Standardschrift, einem gestalteten Titelblock, einfacher Vektorzeichnung und Hinweisen zu den nächsten Schritten, während der gleiche Build-and-Run-Ablauf erhalten bleibt.
Alle Demo-Notizen für Delphi und C++Builder wurden durch browserfreundliche Readme.html-Seiten ersetzt, einschließlich ergänzender Hinweise zu Kennwörtern, eingeschränkten Dateien und Signaturergebnissen; die Demo-Indizes führen Benutzer jetzt zu den HTML-Notizen.

v3.56.39 2026-05-26

Die Speicherpfade der direkten Datei-API bauen Cross-Reference-Nachschlagetabellen jetzt linear auf, wodurch DASaveAsFile und verwandte direkte Speicherpfade bei PDFs mit sehr vielen Objekten oder dichten Seitenbäumen deutlich schneller werden.
Der optimierte Writer erhält die gleiche Semantik der Free-Object-Kette und vermeidet wiederholte Objektnummer-Scans während der vollständigen xref-Erzeugung, wodurch große Direct-Save-Workflows ohne Änderung der öffentlichen API oder des Ausgabe-Vertrags beschleunigt werden.

v3.56.38 2026-05-26

Die normale API-Verschlüsselungsausgabe wurde korrigiert, sodass Encrypt die Trailer-ID /ID erstellt oder erhält, bevor AES-256-Sicherheitsdaten geschrieben werden. Dadurch bleiben verschlüsselte PDFs beim erneuten Laden über EncryptionStatus erkennbar.
Der normale API-Workflow LoadFromFile, Encrypt, SaveToFile, erneutes Laden, Decrypt und SaveToFile bewahrt den verschlüsselten Zustand nun bis zum expliziten Decrypt und entspricht damit dem Verhalten der direkten Datei-API bei großen Legacy-PDFs.

v3.56.37 2026-05-26

TPDFlib.ComparePreflightReports wurde hinzugefuegt: ein zeilenweiser Vergleich fuer Nur-Text-Preflight-Berichte, der volatile Generated:-Zeitstempelzeilen ignoriert und eine leere Zeichenfolge zurueckgibt, wenn der stabile Berichtsinhalt uebereinstimmt.
Die Delphi-Demo PreflightReport unterstuetzt jetzt --compare <file> im Einzeldateimodus, schreibt einen UTF-8-.diff.txt-Bericht und gibt Exitcode 2 zurueck, wenn sich der erzeugte Textbericht von der Baseline unterscheidet.

v3.56.36 2026-05-26

Die Delphi-Demo PreflightReport unterstuetzt jetzt Verzeichnis-Batchlaeufe mit --input-dir, --output-dir und --recursive und schreibt pro PDF einen Bericht als <basename>.preflight.<ext>.
Der Batchmodus schreibt eine UTF-8-Datei preflight-summary.csv, die jedes Quell-PDF, den Pass/Fail-Status, die Problemanzahl und den erzeugten Berichtspfad erfasst, waehrend der bestehende Exit-Code-Vertrag fuer Automatisierung erhalten bleibt.

v3.56.35 2026-05-26

ReportFormat = 3 fuegt CSV-Ausgabe zu TPDFlib.CreatePreflightReportEx und TPDFlib.SavePreflightReportEx hinzu und erzeugt UTF-8-Zeilen fuer Berichtmetadaten, jede ausgewaehlte Compliance-Pruefung, einzelne Problemcodes und Meldungen sowie die abschliessende Zusammenfassung.
Die Delphi-Demo PreflightReport unterstuetzt jetzt --format csv und --csv, sodass Preflight-Laeufe ueber die Befehlszeile Tabellenkalkulationen oder einfache CI-Parser speisen koennen, ohne JSON nachzubearbeiten oder Text auszulesen.

v3.56.34 2026-05-26

Formatbewusste APIs TPDFlib.CreatePreflightReportEx und TPDFlib.SavePreflightReportEx hinzugefügt, um PDF/A- und PDF/UA-1-Preflight-Berichte als Klartext, JSON oder eigenständiges HTML zu erzeugen, während die vorhandenen reinen Text-APIs erhalten bleiben.
Das Delphi-Demo PreflightReport unterstützt jetzt --format text|json|html sowie die Kurzformen --json und --html, sodass derselbe Kommandozeilen-Workflow lesbare Berichte oder maschinenlesbare CI-Artefakte erzeugen kann.

v3.56.33 2026-05-26

TPDFlib.CreatePreflightReport und TPDFlib.SavePreflightReport wurden hinzugefügt, damit Anwendungen wiederverwendbare Klartextberichte aus den integrierten PDF/A- und PDF/UA-1-Konformitätsprüfungen erstellen können, ohne String-List-Handles manuell zu durchlaufen.
Das Delphi-Demo PreflightReport ruft jetzt direkt die Report-APIs der Bibliothek auf, sodass das Beispiel auf Kommandozeilen-Workflow, ausgewählte Prüfungen, First-Issue-Modus und automatisierungsfreundliche Exit-Codes fokussiert bleibt.

v3.56.32 2026-05-26

Ein neues Delphi-Konsolenbeispiel PreflightReport wurde hinzugefügt. Es führt PDF/A- und PDF/UA-1-Prüfungen mit CheckFileCompliance aus, listet die Befunde mit GetStringListCount und GetStringListItem auf und schreibt einen Preflight-Bericht als Textdatei.
Das Beispiel unterstützt die Optionen --input, --output, --pdfa, --pdfua, --both und --first-issue sowie Exit-Codes für automatisierungsfreundliche Ergebnisse: bestanden, Probleme gefunden und Laufzeitfehler.

v3.56.31 2026-05-25

GetCustomKeys(2) verbirgt jetzt konsistent systemweite Einträge, die von der Bibliothek verwaltet werden, einschließlich /OutputIntents, /Extensions, /Requirements, /Collection und /NeedsRendering.
Die von SetPDFAMode erstellten PDF/A-Ausgabe-Intents erscheinen nicht mehr als benutzerdefinierte Katalogschlüssel, wodurch die Anwendungsmetadaten von den PDF-Konformitätsstrukturen getrennt bleiben.

v3.56.25 2026-05-23

Die GetPDFUADiagnostics-Funktion auf der Schreibseite behebt das entsprechende MULTIPLE-H-CHILDREN:N-Problem, wodurch die Funktionalität mit dem 10044-Modus ab v3.56.24 übereinstimmt. ISO 14289-1 §7.4.4 verbietet mehr als ein direktes H-Kind pro Knoten im Tag-Baum – die Schreibseitprüfung wird immer dann ausgelöst, wenn der im Speicher befindliche FStructElems-Baum eine solche Verletzung enthält.
Ein neuer, verschachtelter CountMultipleHChildren-Helfer durchläuft den Baum in der Tiefe und zählt die H-Kinder auf jeder Ebene. Die Prüfung läuft parallel zu den vorhandenen LIST-STRUCT / LIST-NO-NUMBERING-Durchläufen und verwendet das gleiche FStructElems-Traversalmuster.

v3.56.24 2026-05-23

Die PDF/UA-1-Prüfung erhält eine zusätzliche ISO 14289-1 §7.4.4-Prüfung auf Eindeutigkeit von H-Tags. 10044 meldet jeden Strukturknoten, der mehr als ein direktes H-Kind enthält. — verbietet dies in der Spezifikation für stark strukturierte Dokumente, und dieselbe Einschränkung gilt für jeden Knoten im Tag-Baum, unabhängig vom Gesamtstrukturmodus. Die andere §7.4.4 SHALL (ein Dokument muss entweder stark oder schwach strukturiert sein, nicht beides) erfordert dokumentumfassende Heuristiken und wurde absichtlich aus dieser Prüfung ausgelassen.
Ein neuer, vorrangiger Strukturbaum-Durchlauf (UAVisitStructNodeForHUniqueness / ScanStructTreeForHUniqueness) zählt die direkten H-Kinder pro Knoten und durchläuft den Baum in der Tiefe. Verwendet den gleichen K-Form-Decoder wie die vorhandenen Überschrift-/Listen-/Notiz-Durchläufe.

v3.56.23 2026-05-23

Die PDF/UA-1-Prüfung erhält zwei ISO 14289-1 §7.21.6-Fontprogramm-Prüfungen, die die Dictionary-Layer-Prüfungen von v3.56.10 bis zu einer TrueType-Parser-Verfügbarkeit verzögert haben. 10034 meldet nicht-symbolische TrueType-Programme, deren eingebettete SFNT-cmap-Tabelle nur den symbolischen Eintrag (platformID=3, encodingID=0) enthält. — §7.21.6 im ersten Absatz erfordert mindestens eine nicht-symbolische cmap-Untertabelle, damit das Programm die durch seine /Encoding. deklarierten Codepunkte rendern kann. 10035 meldet nicht-symbolische TrueType-Arrays, deren Glyphennamen keine Mitglieder der Adobe Glyph List sind (.notdef ausgenommen). — §7.21.6 im dritten Absatz erfordert, dass jeder Differences-Eintrag in AGL landet.
Das neue Lib/PDFlibPDFUAFontInspect.pas implementiert einen toleranten SFNT-Tabellenverzeichnis-Walker und einen cmap-Untertabelle-Verzeichnis-Parser. Die 4281-Name-Adobe-Glyph-List-Tabelle, die im vorherigen Infrastruktur-Commit als Gerüst hinzugefügt wurde, ist jetzt über die Differences-Prüfung integriert. Programme, die nicht als SFNT (Type 1 PFB / PFA, OpenType-Sammlung, beliebiger Müll) geparst werden, werden stillschweigend übersprungen. Falsch-Negative werden auf der Prüfebene gegenüber Falsch-Positiven bevorzugt.

v3.56.22 2026-05-23

Die PDF/UA-1-Prüfung erhält Prüfungen für Mediendaten. 10042 meldet Mediendaten-Dictionaries (identifiziert durch /S /MCD, optional /Type /MediaClip), denen der erforderliche /CT-Content-Type-Eintrag fehlt. 10043 meldet dieselben Dictionaries, denen das erforderliche /Alt-Array fehlt. ISO 32000-1 Tabelle 274 listet beide Schlüssel als optional auf, aber ISO 14289-1 §7.18.6 macht sie zu erforderlichen, damit Bildschirmlesegeräte eine aussagekräftige Beschreibung für eingebettete Multimedia-Inhalte ausgeben können.
Dies ist Phase 6 des PDF/UA-Deep-Audit-Plans (.superpowers/plans/2026-05-23-pdfua-deep-audit-plan.md). Es läuft ohne Abhängigkeit von einem Fontprogramm- oder Content-Stream-Parser und ist daher die erste Folgeunterklasse nach der v3.56.0..v3.56.13-Serie.

v3.56.21 2026-05-23

Das neue SetSignProcessCommitmentType gibt das signierte Attribut CAdES commitment-type-indication innerhalb des PAdES-B-B SignerInfo aus. Es akzeptiert Integer-Codes von 1 bis 6, die den bekannten ETSI-Commitment-Werten id-cti-ets-proofOfOrigin bis id-cti-ets-proofOfCreation entsprechen; geben Sie 0 an, um es zu löschen. Werte außerhalb des zulässigen Bereichs werden abgelehnt.
Das neue SetSignProcessSignaturePolicy gibt das CAdES signierte Attribut signature-policy-identifier aus (OID 1.2.840.113549.1.9.16.2.15, §5.2.9). Es benötigt die Policy im Format mit Punkten (dotted-decimal), den Hash des Policy-Dokuments als Hexadezimalstring in Großbuchstaben und einen Digest-Algorithmus-Code (1=SHA-1, 2=SHA-256, 3=SHA-384, 4=SHA-512, 0=automatisch /SHA-256). Das Attribut enthält den SignaturePolicyId-Wert zusammen mit sigPolicyId + sigPolicyHash (OtherHashAlgAndValue SEQUENCE).
Beide Attribute sind nur wirksam, wenn der SubFilter-Wert ETSI.CAdES.detached ist (der PAdES-B-B-Pfad); sie erweitern das bestehende rgAuthAttr-Array zusammen mit content-type und signing-certificate-v2. PAdES Tabelle 1, Zeile d), verbietet die Kombination von commitment-type-indication mit dem PDF-Signaturen-Dictionary-Eintrag /Reason; der Aufrufer ist dafür verantwortlich, dass beide nicht gleichzeitig gesetzt werden.

v3.56.20 2026-05-23

Das neue AddPAdESDSSVRI fügt einen Signature VRI Unterdictionary-Eintrag zum DSS hinzu, der zusammengebaut wird, wodurch der Abschnitt 5.4.2.3 der ETSI EN 319 142-1 v1.2.1-Struktur "Validierungsbezogene Informationen" vervollständigt wird. Der Eintrag wird durch den Großbuchstaben-Hex-Wert SHA-1 der Signaturen ' Bytes indiziert; seine Cert / CRL / OCSP Unterarrays werden durch Referenzierung der entsprechenden übergeordneten DSS Streams über 0-basierte Indizes befüllt, die als kommagetrennte Listen angegeben werden (z. B. "0,2,5").
Das zugrunde liegende TSmartPDFDocument.AddPAdESDSSWithVRI verfolgt die Stream-Objektnummern, die für jedes Zertifikat / CRL / OCSP ausgegeben werden, und verwendet diese, um die VRI Unterarrays als indirekte Referenzen in dieselben Streams zu schreiben, auf die die übergeordneten DSS Arrays bereits verweisen, wodurch die Anforderung der Spezifikation erfüllt wird, dass VRI Einträge Speicherplatz mit dem übergeordneten DSS Dictionary teilen. Der ursprüngliche AddPAdESDSS Einstiegspunkt funktioniert weiterhin unverändert für Aufrufer, die keine VRI benötigen.
Jedes pro-Signatur VRI Unterdictionary enthält den optionalen /Type /VRI Marker, sodass Tools, die den Katalog anhand von Type Tags durchlaufen, die Struktur erkennen können, ohne den übergeordneten Pfad erneut auflösen zu müssen.

v3.56.19 2026-05-23

Neuer PAdES-B-T-Workflow zum Anfügen eines RFC 3161 / RFC 5816-Signatur-Zeitstempels (id-aa-signatureTimeStampToken, OID 1.2.840.113549.1.9.16.2.14) an eine bestehende PAdES-B-B-Signatur. NewPAdESSignatureTimeStampProcessFromFile / FromStream / FromString öffnet eine signierte PDF, SetPAdESSignatureTimeStampField benennt das Feld, GetPAdESSignatureValueHashHex gibt den SHA-256 (oder 384 / 512) Hash des Signierers's signatureValue zur Übermittlung an eine TSA zurück, GetPAdESSignatureCMSBytes legt die bestehende CMS-Payload frei, SetPAdESSignatureCMSBytes akzeptiert die augmentierten CMS-Bytes, die der Aufrufer über seine CMS-Bibliothek zusammensetzt, und EndPAdESSignatureTimeStampProcessToFile / ToStream / ToString fügt den neuen CMS in den ursprünglichen /Contents-Platzhalter ein.
BuildPAdESSignatureTimeStampAttribute ist ein zustandsloser Helfer, der ein von TSA ausgestelltes TimeStampToken in das CMS-Attribut einbettet, das SignerInfo.unsignedAttrs erwartet, sodass Aufrufer, die bereits eine CMS-Bibliothek zur Verfügung haben, die OID + SET-Infrastruktur überspringen können.
Der neue SetSignProcessReserveContentsBytes erweitert den /Contents-Platzhalter zum Zeitpunkt der ersten Signatur, sodass das nachträglich augmentierte CMS ohne Überlauf in die ursprüngliche Reservierung passt. Typische von TSA ausgestellte TimeStampTokens fügen 2-6 KB zum SignerInfo hinzu; geben Sie hier 1024-8192 ein, um Spielraum zu lassen. Wenn nicht genügend Reservierung vorhanden ist, gibt der Augmentierungsaufruf 13 (Ausgabepufferüberlauf) zurück.
Die Bibliothek enthält keinen TSA-Client für HTTP; der Aufrufer ruft die TimeStampToken ab (typischerweise 30-50 Zeilen TSP-Anfrage + HTTP-Kontext für z. B. FreeTSA oder DigiCert). Unter Windows würde CMSG_CTRL_ADD_SIGNER_UNAUTH_ATTR im Prinzip die CMS-Injektion in der Bibliothek automatisieren, gibt aber CRYPT_E_INVALID_INDEX (0x80091008) für die vom Aufrufer bereitgestellte CMS-Byte-Pfad-Form PAdES aus, sodass der vom Aufrufer bereitgestellte CMS-Byte-Pfad verwendet wird.

v3.56.18 2026-05-23

Das PAdES-Attribut signing-certificate-v2 enthält jetzt das optionale IssuerSerial-Feld, das von RFC 5035 (ESSCertIDv2) definiert wird. Der ausgegebene Distinguished Name des Signaturzertifikats' ist in einem GeneralName [4] EXPLICIT directoryName-CHOICE innerhalb GeneralNames enthalten, gefolgt von der Zertifikats-Seriennummer als einem ASN.1-INTEGER. Die Seriennummern-Bytes kommen von Windows CryptoAPI (CRYPT_INTEGER_BLOB) im Little-Endian-Format und werden in Big-Endian umgekehrt, wobei ein positives-Integer-Padding-Byte hinzugefügt wird, wenn das höchste Bit gesetzt ist, was der Art und Weise entspricht, wie OpenSSL und BouncyCastle dasselbe Feld ausgeben.
Verifizierer, die den ausgegebenen Namen + Seriennummern-Paar mit ihrem Kandidaten-Set für den Pfadaufbau abgleichen (insbesondere EU DSS im strengen Modus), finden jetzt beide Identifikatoren im Signaturzertifikat-v2-Attribut; die vorherige v3.56.17-Ausgabe lieferte nur die certHash-Referenz.
Neue ASN.1-Helfer DER_IntegerFromLittleEndian (behandelt die Win32-CRYPT_INTEGER_BLOB-Byte-Reihenfolge) und DER_ContextTagExplicit (verpackt eine Payload in einem kontextspezifischen, konstruierten Tag) runden den PDFlibASN1-Mikro-Encoder ab. Neue CERT_INFO / CRYPT_ALGORITHM_IDENTIFIER / CRYPT_INTEGER_BLOB / PCERT_CONTEXT-Deklarationen in PDFlibCryptoAPI geben dem Signaturpfad Zugriff auf die geparsten Zertifikatsfelder.

v3.56.17 2026-05-23

Der eingebaute ETSI.CAdES.detached-Signaturpfad erzeugt nun strukturkonforme PAdES-B-B-Signaturen. Die Bibliothek baut die CMS-authentisierten Attribute selbst auf — content-type (id-data) und signing-certificate-v2 aus RFC 5035 / RFC 5816 mit einem SHA-256-Hash des Signaturzertifikats — und übergibt sie über rgAuthAttr an CryptSignMessage. Sobald dieses Feld nicht NULL ist, hört die Windows CryptoAPI auf, das von PAdES (ETSI EN 319 142-1 v1.2.1 Tabelle 1) verbotene signing-time-Attribut automatisch zu injizieren, sodass das resultierende SignerInfo nur noch die geforderten Attribute trägt.
Die neue PDFlibASN1-Unit stellt einen fokussierten DER (X.690)-Mikro-Encoder bereit — Längenpräfix, OCTET STRING, SEQUENCE, SET, OBJECT IDENTIFIER — der zum Aufbau des SigningCertificateV2-Attributwerts verwendet wird. Der Encoder folgt den Standardregeln für base-128-OID-Arcs und lässt das optionale hashAlgorithm-Feld weg, wenn es lediglich den SHA-256-Standard wiederholen würde, passend zu dem, was OpenSSL und BouncyCastle ausgeben.
ApplySignature leitet ETSI.CAdES.detached nun über den Raw-Byte-Pfad (denselben, den adbe.pkcs7.detached verwendet) statt einen vorberechneten Digest zu übergeben. Die CryptoAPI berechnet das messageDigest-authentisierte Attribut nun über die tatsächlich signierten Inhalte, was Verifier erwarten.
SHA-384 und SHA-512 werden beim Aufbau des signing-certificate-v2-Attributs ebenfalls berücksichtigt: Das hashAlgorithm-Feld wird mit dem passenden AlgorithmIdentifier ausgegeben, statt sich auf den Standard zu verlassen. SHA-1 wird in diesem Kontext stillschweigend auf SHA-256 hochgestuft, weil PAdES-B-B SHA-1 nicht autorisiert (clause 6.2.1).

v3.56.16 2026-05-23

Neu: SetSignProcessDigestAlgorithm wählt den Message-Digest-Algorithmus für die Signatur: 1 = SHA-1 (deprecated), 2 = SHA-256 (moderner Standard), 3 = SHA-384, 4 = SHA-512, 0 = auto (SHA-256 für jeden SubFilter außer dem Legacy-Pfad adbe.pkcs7.sha1, der für byte-stabile Rückwärtskompatibilität bei SHA-1 bleibt). ETSI EN 319 142-1 v1.2.1 §6.2.1 verbietet MD5 und verweist für empfohlene Krypto-Suites auf ETSI TS 119 312, sodass PAdES-Signierer SHA-256 oder stärker wählen sollten.
Hinzugefügt: SHA256StreamRange, SHA384StreamRange und SHA512StreamRange als Hash-Helfer neben dem bestehenden SHA1StreamRange; der Signaturpfad nutzt sie, um den PDF ByteRange unter dem gewählten Algorithmus zu hashen. Die PKCS#7-SignerInfo.digestAlgorithm-OID und die tatsächlich geschriebenen Hash-Bytes stimmen nun garantiert überein (der bisherige Code übergab unabhängig vom ausgehandelten Algorithmus stets den SHA-1-Digest).
TPDFlibPFXFile.SignData nimmt nun einen DigestAlgorithm-Parameter entgegen und wählt für jedes (SubFilter, Algorithmus)-Paar die korrekte OID: 2.16.840.1.101.3.4.2.1 / .2 / .3 für SHA-256/384/512 bei detached- und Custom-SubFiltern (RFC 5754) und die passenden OIDs der sha256WithRSAEncryption-Familie für den Legacy-Pfad adbe.pkcs7.sha1.

v3.56.15 2026-05-23

Neue SetSignProcessDocTimeStamp schaltet einen Signaturprozess in den PAdES-Document-Time-stamp-Modus gemäß ETSI EN 319 142-1 v1.2.1 §5.4.3. Das resultierende Signatur-Wörterbuch trägt /Type /DocTimeStamp und /SubFilter /ETSI.RFC3161, lässt die unzulässigen Schlüssel /M, /Reason, /Location, /ContactInfo und /Name weg und reserviert einen 8192-Byte-Hex-Platzhalter (oder eine vom Aufrufer dimensionierte Größe) in /Contents für ein extern abgerufenes RFC 3161 TimeStampToken.
Passthrough wird automatisch aktiviert, wenn der DocTimeStamp-Modus gewählt ist, weil das TimeStampToken von einer externen TSA stammt. SetSignProcessInfo-Aufrufe nach dem Wechsel in den DocTimeStamp-Modus werden stillschweigend ignoriert, um das Signatur-Wörterbuch spezifikationskonform zu halten.
Die in v3.56.8 hinzugefügte automatische PAdES-/Extensions /ESIC-Injektion deckt DocTimeStamp bereits ab, weil sein SubFilter mit ETSI. beginnt, sodass ein Document-Time-stamp-PDF die erforderliche Catalog-Erweiterung ohne zusätzliche Verdrahtung deklariert.

v3.56.14 2026-05-23

Neue PAdES-Document-Security-Store-(DSS)-Erweiterungs-API. NewPAdESDSSProcessFromFile / NewPAdESDSSProcessFromStream / NewPAdESDSSProcessFromString öffnen eine zuvor signierte PDF, AddPAdESDSSCertificate / AddPAdESDSSCRL / AddPAdESDSSOCSP bereiten DER-codiertes Validierungsmaterial vor, und EndPAdESDSSProcessToFile / EndPAdESDSSProcessToStream / EndPAdESDSSProcessToString schreiben ein inkrementelles Update mit einem /DSS << /Type /DSS /Certs [...] /CRLs [...] /OCSPs [...] >>-Wörterbuch gemäß ETSI EN 319 142-1 v1.2.1 §5.4.2.2. Dies ist der Baustein zur Promotion einer PAdES-B-B / B-T-Signatur zur PAdES-B-LT-Langzeitvalidierung.
Der DSS-Prozess hebt den Catalog-/Extensions /ESIC-Eintrag beim Hinzufügen von Validierungsmaterial automatisch auf mindestens ExtensionLevel 1 an, entsprechend der Anforderung in §5.6, und führt bei wiederholten Aufrufen neue Zertifikate, CRLs und OCSP-Antworten mit den bestehenden /Certs / /CRLs / /OCSPs-Arrays zusammen, sodass Revisionen sich akkumulieren statt zu überschreiben.
GetPAdESDSSProcessResult / ReleasePAdESDSSProcess vervollständigen den Lebenszyklus und spiegeln die bestehende SignProcess-API-Oberfläche.

v3.56.8 2026-05-23

PAdES-Baseline-Konformität: Wenn eine Signatur mit einem PAdES-SubFilter erstellt wird (ETSI.CAdES.detached oder ETSI.RFC3161), erhält das Dokument-Katalog nun automatisch den Eintrag /Extensions /ESIC <</BaseVersion /1.7 /ExtensionLevel 2>>, der von ETSI EN 319 142-1 v1.2.1 §5.6 verlangt wird. Der Eintrag wird durch dasselbe inkrementelle Update hinzugefügt, das die Signatur trägt, stuft niemals einen bestehenden höheren /ExtensionLevel herab und folgt indirekten /Extensions- oder /ESIC-Referenzen, wenn die Quell-PDF sie bereits als separate Objekte speichert.
Der von SetSignProcessCustomSubFilter für über TPDFlib erstellte PDFs geschriebene Adobe-äquivalente Erweiterungsmarker ist nun /ADBE /BaseVersion /1.7 /ExtensionLevel 8 (war ExtensionLevel 5), passend zur alternativen Deklaration, die PAdES-Baseline-Signaturen verwenden dürfen; Level 5 deckte nur ISO 32000-2-Formulare / 3D / RichMedia-Features ab und identifizierte tatsächlich nicht die PAdES-Erweiterungen.

v3.56.13 2026-05-23

Wenn SetPDFUAMode aktiv ist und das Dokument gespeichert wird, erhält jedes L-(Listen-)Strukturelement, dem ein explizites ListNumbering-Attribut fehlt, nun automatisch /O = List /ListNumbering = None. ISO 14289-1 §7.6 verlangt, dass jedes L-Tag seinen Nummerierungsstil deklariert; die neue ApplyPDFUAListNumbering-Korrektur zur Speicherzeit reiht sich in die bestehende Familie ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship / ApplyPDFUAStripTrapNet ein.
Autoren, denen ein bestimmter Listenstil wichtig ist, sollten weiterhin SetStructElemListNumbering vor EndTag aufrufen; die automatische Korrektur greift nur, wenn zur Speicherzeit kein ListNumbering-Attribut vorhanden ist, sodass explizite Werte erhalten bleiben.
Die schreiberseitige LIST-NO-NUMBERING:N-Diagnosemeldung weist nun darauf hin, dass die automatische Korrektur das Problem zur Speicherzeit maskieren wird, sodass Benutzer sowohl das fehlende Attribut als auch das automatische Reparaturverhalten verstehen.

v3.56.12 2026-05-23

Das PDF/UA-1-Audit erhält drei neue ISO 14289-1-Prüfungen. 10031 meldet Link-Annotationen, deren URI-Aktions-Wörterbuch /IsMap = true trägt (verboten durch §7.18.5, sofern nicht an anderer Stelle im Inhalt äquivalente Funktionalität bereitgestellt wird; Autoren mit einem legitimen IsMap-Anwendungsfall können die Diagnose selbst unterdrücken). 10032 meldet Note-Strukturelemente ohne /ID-Eintrag — §7.9 verlangt, dass jedes Note-Tag eine eindeutige ID deklariert. 10033 meldet doppelte Paarzählungen, wenn zwei oder mehr Note-Tags denselben /ID-Wert teilen.
Die Erkennung von Note-ID-Kollisionen erfolgt durch Sammeln der IDs in einer sortierten TStringList und Durchgehen benachbarter Paare, sodass eine Gruppe von drei Notes mit derselben ID als zwei doppelte Paare zählt.
Die URI-Aktions-Prüfung geht das /Annots-Array jeder Seite durch, filtert nach /Subtype /Link und inspiziert dann /A /S /URI und den /IsMap-Boolean. Indirekte Referenzen werden in jedem Schritt dereferenziert, sodass herausgelöste Aktions-Dicts sich genauso verhalten wie Inline-Versionen.

v3.56.11 2026-05-23

ISO 14289-1 §7.6 verlangt, dass jedes L-(Listen-)Strukturelement ein explizites ListNumbering-Attribut trägt. 10030 (reader-seitig) und LIST-NO-NUMBERING:N (writer-seitig) melden L-Tags, die es weglassen. Der reader-seitige Walker decodiert beide /A-Formen (einzelnes Attribut-Wörterbuch oder ein Array von Wörterbüchern gemischt mit Revisions-Integern) und sucht den /ListNumbering-Schlüssel unabhängig vom Owner. Die writer-seitige Prüfung inspiziert TPDFStructElem.Attributes nach demselben Namen sowohl in der finalisierten Strukturliste als auch im noch offenen Tag-Stack.
Gültige ListNumbering-Werte gemäß ISO 32000-1 Tabelle 347 sind None, Disc, Circle, Square, Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha. Das Audit prüft nur das Vorhandensein des Schlüssels, nicht welcher Wert gewählt wurde — jedes L-Tag braucht einen davon.

v3.56.10 2026-05-23

Das PDF/UA-1-Audit erhält die TrueType-Encoding-Regeln aus ISO 14289-1 §7.21.6. 10028 meldet nicht-symbolische TrueType-Schriften, deren /Encoding (oder /BaseEncoding innerhalb eines Encoding-Wörterbuchs) weder MacRomanEncoding noch WinAnsiEncoding ist. 10029 meldet symbolische TrueType-Schriften, die überhaupt einen /Encoding-Eintrag tragen (verboten durch §7.21.6 vierter Absatz).
Symbolisch vs. nicht-symbolisch wird aus FontDescriptor /Flags Bit 3 (Maske 4) entschieden, durch Wiederverwendung der bestehenden UAFontDescriptorSymbolic-Hilfsfunktion aus Unterklasse 4. Der vollständige erste Absatz von §7.21.6 (das eingebettete TrueType-Programm muss passende cmap-Einträge enthalten) erfordert das Parsen des TrueType-Schriftprogramms und ist noch ausstehend; die obigen Wörterbuch-Ebenen-Regeln sind die praktische Ebene, die dieses Audit ohne TrueType-Parser verifizieren kann.
Differences-Array-Regeln in §7.21.6 (nur AGL-Glyph-Namen, Microsoft-Unicode-cmap-Präsenz) bleiben aus demselben Grund außerhalb des Geltungsbereichs — sie erfordern Inspektion des Schriftprogramms.

v3.56.9 2026-05-23

Das PDF/UA-1-Audit erhält eine vollständige ISO 14289-1 §7.18.4-Prüfung. 10027 meldet Widget-Annotationen, deren /StructParent über den /ParentTree des Strukturbaums aufgelöst wird, aber nicht auf einem Strukturelement mit /S = Form landet. Die frühere Teilprüfung aus v3.56.7 (10026) erfasste nur Widgets, denen /StructParent gänzlich fehlt; die neue Prüfung vervollständigt die Regel, indem sie dem Zahlbaum-Zeiger folgt und das Ziel-Tag verifiziert.
Eine neue NumberTreeLookup-Hilfsfunktion implementiert die Zahlbaum-Form aus ISO 32000-1 §7.9.7 (flache /Nums-Wurzel, intermediäre /Kids, bereichsbegrenzt durch /Limits). Zukünftige Audits, die /StructParents-Seiteneinträge oder /PageLabels-Labels auflösen müssen, können sie wiederverwenden.
Die Widget-Annotations-Form-Tag-Verifikation verwendet ein zweistufiges Modell: Ein Widget ohne /StructParent wird als 10026 gemeldet; ein Widget, dessen /StructParent existiert, aber nicht zu /S = Form auflöst, wird als spezifischeres 10027 gemeldet. Dies vermeidet doppelte Zählung derselben Verletzung unter beiden Codes.

v3.56.7 2026-05-23

Wenn SetPDFUAMode aktiv ist und das Dokument gespeichert wird, werden nun alle TrapNet-Annotationseinträge automatisch aus dem /Annots-Array jeder Seite entfernt. ISO 14289-1 §7.18.2 verbietet TrapNet-Annotationen; die neue ApplyPDFUAStripTrapNet-Korrektur zur Speicherzeit reiht sich in die bestehende Familie ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship ein, sodass PDF/UA-Modus-Dokumente nicht mehr stillschweigend TrapNet-Nachzügler ausgeben.
Das PDF/UA-1-Audit erhält eine partielle §7.18.4-Prüfung. 10026 meldet Widget-Annotationen, denen /StructParent fehlt — ein Widget ohne /StructParent kann nicht vom Strukturbaum erreicht werden und kann daher nicht in einem Form-Strukturtag verschachtelt sein. Vollständige strukturelle Verifikation (Auflösung von /StructParent über den ParentTree und Bestätigung, dass das übergeordnete /S Form ist) bleibt einer Folgeversion vorbehalten.
Schreiberseitiges GetPDFUADiagnostics erhält das passende WIDGET-NO-STRUCTPARENT:N-Problem. Die bestehende TRAPNET-ANNOT-Nachricht weist nun auch darauf hin, dass SetPDFUAMode diese zur Speicherzeit automatisch entfernt.

v3.56.6 2026-05-23

Das PDF/UA-1-Audit erhält zwei Prüfungen der Überschriftenhierarchie aus ISO 14289-1 §7.4.2. 10024 meldet, wenn das erste Überschriftenelement in Dokumentreihenfolge nicht H1 (oder H) ist. 10025 meldet die Anzahl der Überschriften-Level-Sprünge in einer absteigenden Sequenz (z. B. H1 gefolgt von H3 ohne H2). Beide Prüfungen teilen einen einzigen Präordnungs-Durchlauf des Strukturbaums, der die verschachtelten /K-Formen decodiert (einzelnes StructElem, Array von StructElems / IndRefs / MCRs).
Schreiberseitiges GetPDFUADiagnostics erhält das passende FIRST-HEADING-NOT-H1-Problem, paritätisch zum reader-seitigen 10024. Die zuvor bestehende schreiberseitige HEADING-LEVEL-SKIP-Prüfung hat nun einen Begleiter, der auch "erste Überschrift war H2"-artige Probleme erfasst.

v3.56.5 2026-05-23

Wenn SetPDFUAMode aktiv ist und das Dokument später verschlüsselt wird, hat der Verschlüsselungs-Berechtigungsschlüssel (/P im Verschlüsselungs-Wörterbuch) nun automatisch Bit 10 (Maske $200, "Text und Grafik zur Unterstützung der Barrierefreiheit extrahieren") gesetzt, selbst wenn der Aufrufer ppCanCopyAccess nicht in TPDFExtraPermissions einbezogen hat, das an Encrypt übergeben wurde. ISO 14289-1 §7.16 verlangt, dass jede verschlüsselte konforme Datei Barrierefreiheits-Extraktion erlaubt, und das Bit ist ansonsten leicht zu übersehen. Das Bit ist immer sicher zu setzen — es gewährt nur Hilfstechnologie zusätzlichen Zugriff, nicht anderen Extraktionspfaden.
Schreiberseitiges GetPDFUADiagnostics erhält ein neues ENCRYPT-NO-ACCESS-Problem, das ausgelöst wird, wenn PDFUAMode an ist und Bit 10 von /P im Verschlüsselungs-Wörterbuch gelöscht ist. Dies erfasst den Aufrufreihenfolge-Grenzfall, in dem der Benutzer zuerst Encrypt() aufgerufen hat und SetPDFUAMode erst danach — die Diagnose weist den Benutzer an, Encrypt() erneut aufzurufen, sodass das Verschlüsselungs-Dict mit dem korrigierten /P erneut ausgegeben wird.

v3.56.4 2026-05-23

Schreiberseitiges GetPDFUADiagnostics erhält fünf neue ISO 14289-1-Prüfungen, sodass das In-Memory-Dokument-Audit dieselben Verletzungen erfasst wie das leser-seitige CheckFileCompliance-Audit mit ComplianceTest=2. SUSPECTS-TRUE markiert MarkInfo/Suspects=true (§7.1: PDF/UA-konforme Dateien erfordern Suspects=false). ROLEMAP-STANDARD-REMAP:N markiert AddRoleMap-Aufrufe, die ein Standard-Struktur-Tag umbenennen würden — §7.1 verbietet die Umbenennung von Standard-Tags. DC-TITLE-MISSING markiert einen leeren XMP dc:title (getrennt von DOCINFO-TITLE-MISSING, das /Info /Title prüft). TRAPNET-ANNOT:N markiert TrapNet-Annotationen (§7.18.2 verbietet sie). ANNOT-PAGE-NO-TABS-S:N markiert Seiten mit Annotationen, deren Seiten-Wörterbuch /Tabs nicht /S ist (§7.18.3 verlangt Strukturbaum-Tab-Reihenfolge auf diesen Seiten).
Schreiber-seitige und leser-seitige PDF/UA-1-Audits sind nun ungefähr gleichwertig: Jedes Problem, das das leser-seitige Audit auf einer gespeicherten Datei aufdeckt, ist auch von der In-Memory-Diagnose erreichbar, mit den Formatkonventionen jeder Funktion (newline-getrennter Text vs. NNNNN-Code-String-Liste).

v3.56.3 2026-05-23

Das PDF/UA-1-Audit erhält seine §7.21-Schriftprüfungen. 10020 meldet jede Nicht-Standard-14-Schrift, deren FontDescriptor FontFile/FontFile2/FontFile3 fehlt (§7.21.4.1: jede gerenderte Schrift muss ihr Programm einbetten). 10021 meldet CIDFontType2-Nachkommen ohne /CIDToGIDMap-Eintrag (§7.21.3.2). 10022 ruft Standard-14-Schriften auf (Helvetica, Times, Courier, Symbol, ZapfDingbats und fette / kursive Varianten), die ohne ein eingebettetes Programm referenziert werden — §7.21.4 NOTE 5 macht klar, dass es für diese Schriften keine Befreiung vom Einbetten gibt. 10023 meldet Schriften, denen eine /ToUnicode-CMap fehlt und die nicht mit der Befreiungsliste aus §7.21.7 übereinstimmen (vordefinierte MacRoman / MacExpert / WinAnsi-Encodings, Type 0 mit Adobe-GB1 / CNS1 / Japan1 / Korea1-Zeichensammlungen, nicht-symbolisches TrueType).
Komposite Type-0-Schriften werden auf beiden Ebenen inspiziert: /ToUnicode auf dem Type-0-übergeordneten Wörterbuch selbst, und Einbettung / /CIDToGIDMap auf dem ersten Nachkommen-CIDFont. Type-3-Schriften überspringen die Einbettungs-Prüfung (ihre Glyphen sind Inline-CharProcs), nehmen aber weiterhin an der /ToUnicode-Prüfung teil.
Die PDFlibPDFA-Hilfsfunktionen für ähnliche Schriftarbeit wurden absichtlich nicht geteilt — ein halbes Dutzend kurzer Routinen (Subset-Präfix-Entfernung, Standard-14-Namenstabelle, FontFile-Präsenz, Symbolic-Flag) sind lokal als UA*-Helfer dupliziert, sodass sich das PDF/A-Audit weiterentwickeln kann, ohne PDF/UA zu brechen, und umgekehrt.

v3.56.2 2026-05-23

Das PDF/UA-1-Audit erhält fünf weitere ISO 14289-1-Prüfungen, die Annotationen, eingebettete Dateien und optionalen Inhalt abdecken. 10015 meldet Link-Annotationen, denen eine nicht-leere /Contents-alternative Beschreibung fehlt (§7.18.5), sodass Screenreader Linkziele ankündigen können. 10016 und 10017 markieren eingebettete-Datei-FileSpec-Wörterbücher, denen die erforderlichen /F- oder /UF-Dateinamenschlüssel fehlen (§7.11). 10018 markiert optionale-Inhalt-Konfigurations-Wörterbücher, die einen nicht-leeren /Name-Textstring weglassen (§7.10). 10019 markiert optionale-Inhalt-Konfigurations-Wörterbücher, die den verbotenen /AS-Schlüssel enthalten (§7.10).
Der pro-Seite-Annotationsdurchlauf, der bereits die TrapNet- und /Tabs /S-Prüfungen antrieb, sammelt nun auch Link- / /Contents-Daten im selben Durchgang, sodass das Audit O(N) auf die Objektanzahl bleibt.

v3.56.1 2026-05-23

Das PDF/UA-1-Audit erhält fünf neue ISO 14289-1-Prüfungen. 10010 verifiziert die Barrierefreiheits-Extraktionsberechtigung (Bit 10 des Verschlüsselungs-/P-Schlüssels) auf verschlüsselten Dateien (§7.16). 10011 erkennt dynamische XFA-Formulare über das Element <dynamicRender>required</dynamicRender> innerhalb des XFA-XDP-Pakets (§7.15). 10012 markiert Form-XObjects, die einen /Ref-Eintrag tragen — Referenz-XObjects sind verboten (§7.20). 10013 markiert TrapNet-Annotationen (§7.18.2). 10014 geht jede Seite durch und meldet jede Seite mit Annotationen, deren Seiten-Wörterbuch nicht /Tabs /S setzt (§7.18.3), sodass die Tab-Reihenfolge dem Strukturbaum folgt.
Alle fünf neuen Codes fließen durch dasselbe CheckFileCompliance + GetStringListItem-Handle-Paar, das die vorherige Version hinzugefügt hat — es gibt keine neue öffentliche API-Oberfläche.

v3.56.0 2026-05-23

Neues leser-seitiges Audit CheckCompliancePDFUA validiert eine externe PDF gegen ISO 14289-1 (PDF/UA-1). Es ergänzt die bestehende schreiberseitige Prüfung GetPDFUADiagnostics, indem es jede Input-PDF akzeptiert (eigene Ausgabe, Scanner-Ausgabe, Drittanbieter-Inhalt) und PDF/UA-1-Verletzungen auf dieselbe Weise auflistet, wie CheckFileCompliance bereits PDF/A-Probleme meldet.
CheckFileCompliance akzeptiert nun ComplianceTest = 2, um das neue PDF/UA-1-Audit auszuführen. Der PDF/A-Test unter ComplianceTest = 1 ist unverändert, und die Issue-Liste fließt weiterhin durch das bestehende GetStringListCount / GetStringListItem-Handle-Paar zurück.
Der erste Wurf deckt die grundlegenden PDF/UA-1-Konformitäts-Gates aus §5 (XMP pdfuaid:part-Identifikation) und §7.1 (Katalog-/Metadata-Stream, Tagged-PDF-Marker, Strukturbaum, Viewer-Titel-Präferenz, Dokumentsprache, XMP dc:title, /Suspects-Wert und das Verbot der Umbenennung von Standard-Struktur-Tags) ab. Acht Diagnose-Codes werden ausgegeben — 10001 bis 10009 — die den numerischen Bereich visuell von den PDF/A-00xxx-Codes trennen.
Tiefere PDF/UA-1-Klauseln (Sicherheit, Annotationen, XObjects, Schrift-Subsetting) werden für Folge-Patch-Releases auf demselben Audit-Framework verfolgt.

v3.55.6 2026-05-22

Jedes frisch generierte XMP-Paket trägt nun eine xmpMM:InstanceID-Eigenschaft im Format uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. Der Bezeichner wird über Win32 CoCreateGuid generiert und gibt jedem erstellten Dokument einen eindeutigen, versionsunabhängigen Fingerabdruck, wie von ISO 19005-1 §6.7.2 (Cor2) und PDF/A-Best-Practice-Guides empfohlen. Die Nicht-Windows-Builds (wo das XMP-Paket leer bleibt) sind unberührt.
Der xmpMM-Namespace (http://ns.adobe.com/xap/1.0/mm/) ist nun Teil der SelectionNamespaces des XMP-Pakets; neue SetXMPMM- und GenerateInstanceID-Hilfsfunktionen unterstützen die InstanceID-Ausgabe und bieten die Grundlage für zukünftige xmpMM:History / xmpMM:DerivedFrom-Unterstützung.
Das PDF/A-Extension-Schema-Beschreibungsschema (pdfaExtension / pdfaSchema / pdfaProperty / pdfaType / pdfaField) wird in dieser Version nicht hinzugefügt. Die Erstellung eines benutzerdefinierten Erweiterungsschemas erfordert eine mehrstufige bag / seq / strukturierte-Eigenschafts-Konstruktion jenseits der aktuellen SetDublinCore / SetXMPBasic-Form; die Arbeit wird für eine zukünftige Version verfolgt. Dokumente, die benutzerdefinierte XMP-Eigenschaften deklarieren müssen, fallen weiterhin auf den LoadFromString-Pfad zurück.

v3.55.5 2026-05-22

PDF/A-Dokumente haben nun ihre Annotations-/F-Flags zur Speicherzeit normalisiert. ISO 19005-1 §6.5.3 verlangt, dass das Print-Bit auf 1 und die Hidden- / Invisible- / NoView-Bits auf 0 auf jeder Annotation gesetzt sind; der Writer wendet diese Maske nun zur Speicherzeit an, sodass Aufrufer sich nicht das Bit-Layout merken müssen. Der /Subtype /Popup-Fall ist ausgenommen — Popups sind Kinder anderer Annotationen und werden traditionell nicht gedruckt.
Das AcroForm-/NeedAppearances-Flag wird nun zur Speicherzeit auf false zwangsgesetzt, wenn das Dokument in einem beliebigen PDF/A-Modus ist. ISO 19005-1 §6.9 verlangt, dass das Flag fehlt oder false ist; zuvor ließ der Writer den Wert, den der Aufrufer gesetzt hatte, was Dokumente produzierte, die den Viewer baten, Erscheinungen zur Öffnungszeit neu zu generieren, und die Spezifikation stillschweigend verletzten, wenn der Aufrufer ihn auf true gesetzt hatte. Der Fix läuft auch für Dokumente, denen das Flag zuvor fehlte — der Writer gibt ein explizites /NeedAppearances false aus, um dem Validator keine Mehrdeutigkeit zu lassen.

v3.55.4 2026-05-22

AddStandardFont weist nun Aufrufe im PDF/A-Modus zurück. ISO 19005-1 §6.3.4 widerruft die "Standard 14 darf uneingebettet sein"-Befreiung aus der PDF-Referenz: Jedes Schriftprogramm in einer konformen Datei muss eingebettet sein, und die Bibliothek bündelt die Standard-14-Umrisse nicht. Die Fassade gibt stillschweigend 0 zurück; Aufrufer sollten zu AddTrueTypeFont oder AddType1Font mit einer echten Schriftdatei wechseln.
AddTrueTypeFont befördert nun Embed=0 (keine Einbettung) stillschweigend zu Embed=1 (vollständige Schrift einbetten), wenn der PDF/A-Modus aktiv ist. Der nicht-eingebettete Referenzpfad produzierte PDFs, die vom Schrift-Fallback des Viewers auf eine System-Arial- / Times- / Courier-Installation abhängig waren, was gegen ISO 19005-1 §6.3.4 verstößt. Bestehende Aufrufer, die um Einbettung baten (Embed=1 oder 2), sind unberührt.
Die nicht-symbolische TrueType-/Encoding-Konformitätsprüfung (ISO 19005-1 §6.3.7 Cor2 verlangt WinAnsi oder MacRoman als Encoding-Namen oder BaseEncoding, ohne /Differences) wird in dieser Version nicht hinzugefügt, weil die Bibliothek bereits /WinAnsiEncoding für nicht-symbolische TrueType-Subsets ausgibt, und die tiefere Durchsetzung erforderte das Verfolgen des symbolisch-vs-nicht-symbolisch-Dispatchs durch den Subset-Pfad. CheckCompliancePDFA 00034 / 00035 (hinzugefügt v3.51.0) markiert jede nicht-konforme Ausgabe zur Validierungszeit.

v3.55.3 2026-05-22

TrueType-gestützte CIDFontType2-Schrift-Wörterbücher tragen nun /CIDToGIDMap /Identity explizit. ISO 19005-1 §6.3.3.2 (Cor2) verlangt, dass der Eintrag für jeden eingebetteten Type-2-CIDFont vorhanden ist; die PDF-Referenz erlaubt den impliziten Identity-Standard, aber PDF/A verlangt einen expliziten Wert. Der Writer ließ den Schlüssel zuvor völlig weg, was veraPDF (und CheckCompliancePDFA 00033 hinzugefügt in v3.51.0) dazu brachte, die Datei zu markieren. Der /Identity-Name entspricht dem GID-as-CID-Layout, das der Writer bereits implizit produzierte, sodass bestehende Dokumente identisch rendern.
FontDescriptor /CharSet (für Type-1-Subsets) und /CIDSet (für CIDFont-Subsets) bleiben TODO; der Writer müsste verfolgen, welche Glyph-Namen / CIDs im Subset landeten, um sie genau zu füllen. CheckCompliancePDFA 00031 und 00032 (ebenfalls hinzugefügt in v3.51.0) markieren das Fehlen, sodass Benutzer das Problem zur Validierungszeit sehen.

v3.55.2 2026-05-22

AddImageDirectFromString weist nun PDF/A-inkompatible Filter am Eintrittspunkt zurück. Die Übergabe von Filter = 'LZWDecode' wird für jeden PDF/A-Teil zurückgewiesen (ISO 19005-1 §6.1.10 plus die äquivalenten ISO 19005-2 / -3-Regeln). Die Übergabe von Filter = 'JBIG2Decode' oder 'JPXDecode' wird für PDF/A-1 (Modi 1 und 2) zurückgewiesen. PDF/A-2 und PDF/A-3 erlauben JPXDecode gemäß ISO 19005-2 §6.2.8.3 mit Sub-Spezifikations-Bedingungen (Farbkanal-Anzahl, Bit-Tiefen-Einheitlichkeit, METH/APPROX-Anforderungen), die das schreiber-seitige Gate nicht erzwingt — Aufrufer in diesen Modi müssen weiterhin sicherstellen, dass der JPEG-2000-Stream konform ist. Die Fassade gibt stillschweigend 0 zurück, wenn ein verbotener Filter angefordert wird.
TIFF-, PNG-, JPEG- und JPEG-2000-Eingaben, die durch AddImageFromFile / AddImageFromStream geladen werden, sind unberührt: Der Importer dekomprimiert die Quell-Bytes und re-encodiert mit FlateDecode (oder DCTDecode für JPEG-Nutzdaten), sodass LZW-Eingabe nie zur Output-Filter-Kette propagiert. Der in v3.50.0 (00004) und v3.52.0 (00022, 00023) hinzugefügte CheckCompliancePDFA-Validator bietet eine zweite Verteidigungslinie zur Validierungszeit für jeden indirekten Pfad, der noch einen verbotenen Filter in die Ausgabe schlüpfen lässt.

v3.55.1 2026-05-22

AddLinkToHideField weist nun Aufrufe im PDF/A-Modus zurück. Die frühere Version hinterließ einen Kommentar, der behauptete, die Aktion sei PDF/A-kompatibel, aber ISO 19005-1 Cor2 fügte /Hide zur Liste der verbotenen Aktionen hinzu (§6.6.1), und ISO 19005-2 / -3 erben die Beschränkung. Die Fassade gibt stillschweigend 0 zurück, wenn sie im PDF/A-Modus aufgerufen wird, passend zu AddLinkToJavaScript und AddLinkToImportData.
AddSWFAnnotationFromFile weist nun Aufrufe im PDF/A-Modus zurück. SWF- / RichMedia-Annotationen umschließen Flash-Medien, was von ISO 19005-1 §6.5.2 (keine Movie- / Sound-Subtypes) verboten und durch ISO 19005-2 §6.3.1 (kein 3D / Sound / Screen / Movie) verstärkt wird. Die Fassade gibt stillschweigend 0 zurück.
AddEmbeddedFile und AddLinkToEmbeddedFile weisen nun Aufrufe in PDF/A-1- und PDF/A-2-Modi zurück. ISO 19005-1 §6.1.11 verbietet /EF, und ISO 19005-2 §6.8 erlaubt nur eingebettete PDF/A-Dateien; statt die rekursive PDF/A-Konformität der angehängten Nutzdaten zu verifizieren, verweigert der Writer einfach den Aufruf in diesen Modi. PDF/A-3 (SetPDFAMode 5 oder 6) bleibt zulässig — siehe v3.55.0 für die automatische /AFRelationship-Injektion.
SetOpenActionMenu weist nun MenuItem-Werte außerhalb der Whitelist {NextPage, PrevPage, FirstPage, LastPage} zurück, wenn das Dokument im PDF/A-Modus ist. ISO 19005-1 §6.6.1 schränkt benannte Aktionen auf diesen Satz ein, sodass die API zuvor stillschweigend nicht-konforme Find- / Print- / FullScreen-Open-Action-Wörterbücher produzierte, die veraPDF zurückweisen würde.
NewOptionalContentGroup weist nun Aufrufe in PDF/A-1-Modi (SetPDFAMode 1 oder 2) zurück. ISO 19005-1 §6.1.13 verbietet den Katalog-/OCProperties-Schlüssel. PDF/A-2 (Modi 3/4) und PDF/A-3 (Modi 5/6) erlauben optionalen Inhalt mit den Bedingungen in ihren jeweiligen §6.9, sodass das Gate nur für PDF/A-1 auslöst.

v3.55.0 2026-05-22

PDF/A-3-Dokumente erhalten nun automatisch einen /AFRelationship-Eintrag auf jeder eingebetteten Datei. Zuvor konnte eine mit der Bibliothek erstellte PDF/A-3-Datei die Validierung nicht bestehen, weil ISO 19005-3 Anhang E, Tabelle E.1 AFRelationship auf jeder eingebetteten Dateispezifikation verlangt. Der Writer injiziert nun den konfigurierten Standardwert (out of the box 'Unspecified') auf jedem FileSpec-Wörterbuch, dem zur Speicherzeit der Eintrag fehlt, und spiegelt die früher eingeführte PDF/UA-AFRelationship-Automatik wider. Nur PDF/A-3-Modi (SetPDFAMode 5 = PDF/A-3b oder 6 = PDF/A-3a) lösen die automatische Injektion aus; PDF/A-1 und PDF/A-2 weisen eingebettete Dateien gemäß ISO 19005-1 §6.1.11 und ISO 19005-2 §6.8 weiterhin grundsätzlich zurück.
SetPDFA3DefaultAFRelationship ist eine neue API, die den vom Writer geschriebenen Standardwert überschreibt, wenn einer eingebetteten Datei ein /AFRelationship-Eintrag fehlt. Akzeptiert die Werte aus ISO 19005-3 Tabelle E.1 'Source' (die eingebettete Datei ist das Quellmaterial, das den PDF-Inhalt produzierte), 'Data' (die Datei sind die strukturierten Daten hinter einer visuellen Tabelle oder Grafik), 'Alternative' (eine alternative Darstellung wie eine Audio-Version), 'Supplement' (eine ergänzende Darstellung wie eine MathML-Form einer Gleichung), 'Unspecified' (Beziehung kann nicht durch die obigen charakterisiert werden) oder jeden registrierten Second-Class-Namen. Leere Zeichenkette setzt auf 'Unspecified' zurück. Pro-Datei-Überschreibungen bleiben über SetEmbeddedFileAFRelationship verfügbar.
Die neuen APIs werden auf der Delphi-Fassade als TPDFlib.SetPDFA3DefaultAFRelationship und über die DLL als DLSetPDFA3DefaultAFRelationship (PWideChar) und DLSetPDFA3DefaultAFRelationshipA (PAnsiChar) verfügbar gemacht.

v3.54.0 2026-05-22

LoadOutputIntentProfile ist eine neue API, die das mitgelieferte sRGB-OutputIntent-Profil durch ein externes, von der Festplatte geladenes ICC-Profil ersetzt. Erforderlich beim Produzieren von PDF/A-Dokumenten in DeviceCMYK- oder DeviceGray-Farbräumen, da die Bibliothek nur ein sRGB-Profil liefert. Typische Verwendung ist, zuerst SetPDFAMode aufzurufen (das die OutputIntent-Skeleton initialisiert), dann LoadOutputIntentProfile('C:\\path\\to\\FOGRA39.icc', 'DeviceCMYK'), um die Profilbytes auszutauschen und das Dokument mit dem neuen Farbraum zu kennzeichnen. Gibt 1 bei Erfolg zurück, 0 bei Datei-nicht-gefunden oder unbekanntem Farbraum. Auf der Delphi-Fassade als TPDFlib.LoadOutputIntentProfile und über die DLL als DLLoadOutputIntentProfile (PWideChar-Form) und DLLoadOutputIntentProfileA (PAnsiChar-Form) verfügbar. ISO 19005-1 §6.2.2 erlaubt jedes registrierte ICC-Profil im DestOutputProfile-Stream.
SetFillColorCMYK, SetTextColorCMYK, SetTextHighlightColorCMYK, SetTextUnderlineColorCMYK, AddSeparationColor, SetFillColorSep, SetLineColorSep, SetTextHighlightColorSep und SetTextColorSep gelingen nun im PDF/A-Modus, wenn das OutputIntent-Profil des Dokuments DeviceCMYK ist. Zuvor wiesen diese APIs jeden Aufruf im PDF/A-Modus unabhängig vom OutputIntent zurück, was die Erstellung konformer CMYK-Dokumente verhinderte. Das Gate ist nun PDFAMode = 0 ODER OutputIntentColorSpace = 'DeviceCMYK', passend zur Regel aus ISO 19005-1 §6.2.3.3, dass DeviceCMYK erlaubt ist, wenn das OutputIntent ein CMYK-Profil verwendet, und ISO 19005-1 §6.2.3.4, das Separation-Alternativen erlaubt, deren Basisfarbraum ebenfalls konform ist.
SetTextShader gelingt nun im PDF/A-Modus, wenn das OutputIntent-Profil entweder DeviceRGB oder DeviceCMYK ist. Shader selbst sind nicht durch PDF/A verboten; der Validator (Leseseite) verifiziert, dass der interne Farbraum des Shaders mit dem OutputIntent übereinstimmt. Das frühere strikte Zurückweisungsverhalten verweigerte die konforme Shader-Verwendung.
Das CMYK- / Separation- / Shader-Entsperren hängt vom OutputIntentColorSpace-Tag ab, das von AddOutputIntent und LoadOutputIntentProfile (eingeführt in v3.53.0) gesetzt wird. Der Aufruf von SetPDFAMode ohne LoadOutputIntentProfile hält den Farbraum als DeviceRGB (das mitgelieferte sRGB-Profil), sodass CMYK-Aufrufe standardmäßig weiterhin zurückweisen — das neue Verhalten ist Opt-in über LoadOutputIntentProfile.

v3.53.0 2026-05-22

Das OutputIntent-Wörterbuch trägt nun die vollständigen PDF/A-Skeleton-Felder, die von ISO 19005-1 §6.2.2 und Adobe Acrobat Preflight empfohlen werden: /OutputCondition (menschenlesbare Farbbedingungsbeschreibung), /Info (Langform-Identifikationstext) und /RegistryName (Registry-URL, Standard http://www.color.org). Die Werte sind standardmäßig "sRGB IEC61966-2.1" / "sRGB IEC61966-2.1" / "http://www.color.org" für die Legacy-Einzelargument-Aufrufstellen; die neue AddOutputIntent-Überladung nimmt die vier benutzerdefinierten Felder direkt entgegen, sodass Aufrufer sie für ihre eigenen Farbbedingungen füllen können.
AddOutputIntent erhält eine neue Fünf-Argument-Überladung: AddOutputIntent(ColorSpace, OutputConditionIdentifier, OutputCondition, Info, RegistryName). Die Legacy-Einzelargument-Form funktioniert unverändert weiter; sie delegiert nun an die neue Überladung mit den sRGB-Standardwerten. Das ColorSpace-Argument wählt auch die /N-Komponentenanzahl, die in das Wörterbuch des eingebetteten ICC-Profils geschrieben wird (3 für DeviceRGB, 4 für DeviceCMYK, 1 für DeviceGray); das eingebettete Profil selbst bleibt der mitgelieferte sRGB-Stream, bis die kommende LoadOutputIntentProfile-API in v3.54.0 ausgeliefert wird.
TPDFDocument stellt OutputIntentColorSpace als Lese-/Schreib-Eigenschaft bereit, die den Farbraum des letzten AddOutputIntent-Aufrufs verfolgt. Dies wird die Gate-Bedingung für die schreiber-seitigen CMYK- / Separation- / Shader-Beschränkungen in v3.54.0, wo Farb-APIs, die heute jeden Aufruf im PDF/A-Modus zurückweisen, nur dann zurückweisen, wenn der Farbraum nicht mit dem OutputIntent übereinstimmt.

v3.52.0 2026-05-22

CheckCompliancePDFA auditiert nun Annotationen, Grafikzustand, Aktionen und Form-XObjects und vervollständigt damit die Abdeckung des PDF/A-Leseseite-Validators für ISO 19005-1 Kapitel 6.2-6.6 und die äquivalenten PDF/A-2/-3-Differentialregeln. Der Validator meldet 14 neue Issue-Klassen (00050-00067): verbotene Annotations-Subtypen (00050; ISO 19005-1 §6.5.2 verbietet FileAttachment / Sound / Movie für PDF/A-1, und ISO 19005-2 §6.3.1 verbietet 3D / Sound / Screen / Movie für PDF/A-2 und PDF/A-3), Annotations-/CA anders als 1.0 (00051; §6.5.3), Annotations-/F fehlend oder mit Print=0 / Hidden=1 / Invisible=1 / NoView=1 (00052; §6.5.3, mit /Subtype /Popup ausgenommen), Annotations-/AA (00054; §6.6.2), Annotations-Erscheinungs-Dict mit anderen Schlüsseln als /N oder nicht-konformem /N-Wert (00055; §6.5.3 Cor2), Widget-Annotation mit /A (00056; §6.9), ExtGState /TR (00058; §6.2.8), ExtGState /TR2 anders als /Default (00059; §6.2.8) und nur in PDF/A-1: ExtGState /SMask anders als /None (00061; §6.4), /BM anders als Normal oder Compatible (00062; §6.4), /CA oder /ca anders als 1.0 (00063; §6.4).
Action-anywhere-Audit (00064, 00065) ersetzt die nur OpenAction-Prüfung aus v3.50.0 durch einen vollständigen Sweep, der verbotene /S-Aktionswerte (Launch, Sound, Movie, ResetForm, ImportData, JavaScript, Hide, SetState, NOP, Trans, GoTo3DView, Rendition, SetOCGState) und benannte Aktionen, deren /N außerhalb von {NextPage, PrevPage, FirstPage, LastPage} liegt, unabhängig davon, wo die Aktion lebt (Annotation /A, Widget /A, Outline /A, Catalog /OpenAction usw.), markiert. ISO 19005-1 §6.6.1.
XObject-Audit (00066, 00067) meldet PostScript- und Reference-XObjects sowie verbotene Schlüssel auf Form-XObjects (/OPI, /PS, /Subtype2 = /PS) und Image-XObjects (/Alternates, /OPI, /Interpolate true). ISO 19005-1 §6.2.4 - §6.2.7.

v3.51.0 2026-05-22

CheckCompliancePDFA auditiert nun zusätzlich zu den in v3.50.0 hinzugefügten strukturellen Prüfungen Schrift- und Farbraum-Konformität. Der Validator meldet neun neue Issue-Klassen: mindestens ein Schriftprogramm ist nicht eingebettet (00030; ISO 19005-1 §6.3.4 verlangt, dass jedes Schriftprogramm, einschließlich der Standard-14-Ersetzungen, eingebettet ist), Type-1-Subset ohne /CharSet in seinem FontDescriptor (00031; §6.3.5), CIDFont-Subset ohne /CIDSet (00032; §6.3.5), CIDFontType2 ohne /CIDToGIDMap (00033; §6.3.3.2 Cor2), nicht-symbolisches TrueType mit nicht-konformem /Encoding (00034; §6.3.7 Cor2 verlangt WinAnsi/MacRoman direkt oder als BaseEncoding, ohne /Differences), symbolisches TrueType, das noch /Encoding trägt (00035; §6.3.7 Cor2), mindestens eine Schrift ohne /ToUnicode in PDF/A-Na- oder PDF/A-Nu-Dokumenten (00036; §6.3.8 Vier-Klassen-Befreiung angewendet), ICCBased-Farbraum, der seinen Profil-Stream nicht einbettet (00037; §6.2.3.2), und eine Datei, die sowohl DeviceRGB als auch DeviceCMYK verwendet (00038; §6.2.3.3 verbietet die Mischung).
Die /ToUnicode-Prüfung (00036) ist auf Konformitätsstufen A und U beschränkt, weil nur diese Stufen Unicode-Mapping gemäß ISO 19005-1 §6.3.8 und ISO 19005-2 §6.2.11.7 verlangen. Level-B-Dateien (PDF/A-1b, PDF/A-2b, PDF/A-3b) werden nicht markiert. Die Vier-Klassen-Befreiung erkennt vordefinierte Encodings (MacRomanEncoding, MacExpertEncoding, WinAnsiEncoding), Standard-14-Type-1-BaseFonts als Proxy für Adobe-Standard-Latin- / Symbol-Glyph-Namen-Schriften und Type-0-Schriften, deren Nachkomme-CIDFont Adobe-GB1, Adobe-CNS1, Adobe-Japan1 oder Adobe-Korea1-Registries verwendet, an.
Das Schrift-Audit geht jedes Font-Wörterbuch durch, klassifiziert es nach Subtype (Type1, MMType1, TrueType, Type3, Type0 mit seinem Nachkommen CIDFontType0 oder CIDFontType2) und dispatcht dann die relevanten Prüfungen. Type-0-Komposit-Schriften delegieren Einbettungs- und Subset-Prüfungen an ihren Nachkommen-CIDFont, während /ToUnicode auf dem Type-0-Wrapper bleibt. Subset-Erkennung verwendet die Standard-Konvention mit sechs Großbuchstaben-Präfix.

v3.50.0 2026-05-22

CheckCompliancePDFA meldet nun 15 zusätzliche PDF/A-Nicht-Konformitätsprobleme, die der Validator zuvor übersah: fehlendes Trailer-/ID-Array (00013), fehlender Dokument-Katalog-/Metadata-Stream (00014), /Filter auf den /Metadata-Stream angewendet (00015), Stream-Wörterbücher, die über /F, /FFilter oder /FDecodeParms auf externe Dateien verweisen (00016), eingebettete Dateien, die über /EF in einem beliebigen Dateispezifikations-Wörterbuch oder über den Name-Tree-/EmbeddedFiles-Eintrag in PDF/A-1-Dokumenten deklariert sind (00017, 00018), /OpenAction, das auf einen verbotenen Aktionstyp zeigt (00019), /AA-zusätzliche-Aktionen-Wörterbücher im Dokument-Katalog oder einer beliebigen Seite (00020, 00021), JBIG2Decode- oder JPXDecode-Filter in PDF/A-1-Dokumenten (00022, 00023), Crypt-Filter, deren /Name nicht /Identity ist (00024), /Requirements im Dokument-Katalog (00025), /Perms mit anderen Schlüsseln als /UR3 und /DocMDP (00026) und /AcroForm /NeedAppearances auf true gesetzt (00027). Der Validator markiert nun verbotene Katalog-/OpenAction-Aktionstypen (/Launch, /Sound, /Movie, /ResetForm, /ImportData, /JavaScript, /Hide, /SetState, /NOP, /Trans, /GoTo3DView, /Rendition, /SetOCGState) und benannte-Aktions-/N-Werte außerhalb der {NextPage, PrevPage, FirstPage, LastPage}-Allowlist gemäß ISO 19005-1 §6.6.1.
Der PDFAID-Parser akzeptiert das U-Konformitätssuffix (PDF/A-2U, PDF/A-3U) neben den bestehenden A- und B-Varianten, sodass CheckCompliancePDFA keine störende "00005 PDFA Mark NOT Found or invalid"-Warnung mehr auslöst, wenn eine von einem anderen Tool produzierte PDF/A-2U- oder PDF/A-3U-Datei gescannt wird. Die in ISO 19005-2:2011 hinzugefügten Unicode-Mapping-Konformitätsstufen werden nun vom Validator erkannt.
Filter-spezifische Prüfungen (JBIG2Decode, JPXDecode) und eingebettete-Datei-Prüfungen (/EF, /EmbeddedFiles) bleiben auf PDF/A-1 beschränkt, weil ISO 19005-2 §6.2.8.3 und §6.8 diese Beschränkungen für PDF/A-2 und PDF/A-3 explizit lockern. Dokumentstruktur-Prüfungen (/Metadata, /AcroForm /NeedAppearances, /OpenAction, /AA, /Requirements, /Perms) gelten für jeden PDF/A-Teil.

v3.49.0 2026-05-21

AddLinkToImportData erstellt eine Link-Annotation, deren Aktion eine PDF-Import-Data-Aktion (/S /ImportData) ist, die die AcroForm-Felder des Dokuments aus einer externen FDF-Datei füllt, wenn der Benutzer auf den Link klickt (ISO 32000-1 §12.6.4.8, Tabelle 198). Der Parameter FileName wird als Filespec-Wörterbuch referenziert und folgt denselben Pfadnormalisierungsregeln wie AddLinkToFile / AddLinkToFileEx (Backslashes werden gemäß ISO 32000-1 §7.11.2.1 in Forward-Slashes umgewandelt). Bit 0 von Options schaltet den sichtbaren Rahmen um, und Bits 1–3 wählen den Link-Highlight-Modus (Invert, Outline, Push), passend zu den vorhandenen AddLinkTo*-Konventionen. PDF 1.4 oder höher. In PDF/A NICHT erlaubt, da die Aktion eine externe Ressource referenziert; die Fassade gibt im PDF/A-Modus stillschweigend 0 zurück. Verfügbar in der Delphi-Bibliothek und in der DLL-Schnittstelle als DLAddLinkToImportData / DLAddLinkToImportDataA (PWideChar- und PAnsiChar-Form).

v3.48.0 2026-05-21

AddLinkToHideField erstellt eine Link-Annotation, deren Aktion eine PDF-Hide-Aktion (/S /Hide) ist, die die Sichtbarkeit eines oder mehrerer AcroForm-Felder umschaltet, wenn der Benutzer auf den Link klickt (ISO 32000-1 §12.6.4.10, Tabelle 196). FieldNames akzeptiert einen oder mehrere vollständig qualifizierte Feldnamen, getrennt durch Kommas, Semikolons oder Zeilenumbrüche; ein einzelner Name wird als Textzeichenfolge in /T geschrieben, zwei oder mehr Namen als Array, beide Formen sind durch die Spezifikation zugelassen. HideFlag wählt die Sichtbarkeitsrichtung: Ein Wert ungleich Null blendet die aufgeführten Felder aus (/H true), Null zeigt sie an (/H false). Bit 0 von Options schaltet den sichtbaren Rahmen um, und Bits 1–3 wählen den Link-Highlight-Modus (Invert, Outline, Push), passend zu AddLinkToWeb / AddLinkToNamedAction. PDF 1.2 oder höher. PDF/A-kompatibel, da keine externe Ressource referenziert wird. Verfügbar in der Delphi-Bibliothek und in der DLL-Schnittstelle als DLAddLinkToHideField / DLAddLinkToHideFieldA (PWideChar- und PAnsiChar-Form).

v3.47.0 2026-05-21

AddLinkToNamedAction erstellt eine Link-Annotation, deren Aktion eine PDF-Named-Action (/S /Named) ist, die einen der vier standardisierten Viewer-Navigationsbefehle auslöst, die in ISO 32000-1 §12.6.4.11, Tabelle 194 definiert sind: NextPage, PrevPage, FirstPage und LastPage. Der Parameter NamedActionType wählt den Befehl (0=NextPage, 1=PrevPage, 2=FirstPage, 3=LastPage); Werte außerhalb dieses Bereichs fallen auf NextPage zurück, sodass der Writer immer einen spezifikationskonformen /N-Namen ausgibt. Bit 0 von Options schaltet den sichtbaren Rahmen um, und Bits 1–3 wählen den Link-Highlight-Modus (Invert, Outline, Push), passend zu den vorhandenen AddLinkToWeb / AddLinkToPage-Konventionen. Die Annotation erfordert PDF 1.1 oder höher und ist mit PDF/A kompatibel, da keine externe Ressource referenziert wird. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.

v3.46.1 2026-05-21

AddCaretAnnotation erstellt eine Caret-Markup-Annotation (PDF /Subtype /Caret) am angegebenen Rechteck und markiert eine Position auf der Seite, an der Text oder Inhalt eingefügt, weggelassen oder anderweitig auf Reviewer-Aufmerksamkeit erfordert. Unterstützt zwei Symboltypen (None und Paragraph) über SymbolType (0 / 1), konfigurierbare Farbe, Deckkraft, Titel, Inhalt und Erstellungs-/Änderungszeitstempel. Definiert in ISO 32000-1 §12.5.6.11. PDF 1.5 oder höher. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.
Dieser Eintrag schließt die Geometrie-Annotations-Ergänzung ab, die mit v3.44.0 Square+Circle begann. PDFlibPas erstellt nun Text-, Stamp-, FreeText-, TextMarkup- (Highlight/Underline/Squiggly/StrikeOut), Square-, Circle-, Line-, Polygon-, PolyLine-, Ink- und Caret-Annotationen, zusätzlich zur bestehenden Unterstützung für Link, FileAttachment, SVG, U3D und SWF.

v3.46.0 2026-05-21

AddInkAnnotation erstellt eine Ink-Markup-Annotation (PDF /Subtype /Ink), die handgeschriebene Striche oder freihand gezeichnete Markierungen auf der Seite repräsentiert. Striche werden als einzelne Zeichenkette geliefert, in der mehrere Striche durch '|' oder Zeilenumbruch getrennt sind und innerhalb jedes Strichs die Koordinatenpaare demselben Leerzeichen-/Komma-/Semikolon-/Tab-Format folgen, das AddPolygonAnnotation verwendet. Zum Beispiel beschreibt "100 100 110 105 120 110 | 200 200 210 205" zwei getrennte Striche. Unterstützt konfigurierbare Rahmenbreite, Tintenfarbe, Deckkraft, Titel, Inhalt und Zeitstempel. Definiert in ISO 32000-1 §12.5.6.13. PDF 1.3 oder höher. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.
Jeder Strich muss eine gerade Anzahl von Werten enthalten (mindestens vier), andernfalls gibt der Aufruf 0 zurück und es wird keine Annotation geschrieben. Das /Rect wird automatisch aus dem kombinierten Bereich aller Striche plus einem kleinen Padding berechnet, sodass die Striche innerhalb der Annotations-Begrenzungsbox bleiben.

v3.45.0 2026-05-21

AddPolygonAnnotation erstellt eine geschlossene Polygon-Markup-Annotation (PDF /Subtype /Polygon) mit Eckpunkten, die als Zeichenkette aus durch Leerzeichen, Kommas, Semikolons oder Tabulatoren getrennten Koordinatenpaaren geliefert werden (z. B. "100 100 200 100 200 200 100 200"). Unterstützt konfigurierbare Rahmenbreite, Rahmenfarbe, optionale Innenfüllfarbe, Deckkraft, Titel, Inhalt und Zeitstempel. Definiert in ISO 32000-1 §12.5.6.9. PDF 1.5 oder höher. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.
AddPolyLineAnnotation erstellt eine offene Polylinien-Markup-Annotation (PDF /Subtype /PolyLine) mit demselben Eckpunkt-Zeichenkettenformat und konfigurierbaren End-Linien-Stilen an beiden Enden (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash). Definiert in ISO 32000-1 §12.5.6.9. PDF 1.5 oder höher. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.
Beide Annotationen erfordern mindestens zwei Eckpunkte (vier Zahlen) und eine gerade Gesamtanzahl von Zahlen; der Aufruf gibt 0 zurück, wenn die Eckpunktzeichenkette nicht in eine gültige Paarliste geparst werden kann. Das /Rect wird aus dem Eckpunktbereich plus einem zur Rahmenbreite proportionalen Padding berechnet, sodass die Endverzierungen sichtbar bleiben.
Beide Annotationen heben die Dokumentversion auf PDF 1.5 an, wenn sie unter einer niedrigeren Mindestversion-Sperre ausgegeben werden.

v3.44.1 2026-05-21

AddLineAnnotation erstellt eine Linien-Markup-Annotation (PDF /Subtype /Line) zwischen zwei Endpunkten, mit konfigurierbarer Rahmenbreite, Linienfarbe, optionaler Innenfüllfarbe, End-Linien-Stilen für beide Enden (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash), Deckkraft, Titel, Inhalt und Erstellungs-/Änderungszeitstempeln. Definiert in ISO 32000-1 §12.5.6.7. PDF 1.3 oder höher. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.
Das /Rect der Annotation wird aus den zwei Endpunkten plus einem zur Rahmenbreite proportionalen Padding berechnet, sodass die Endverzierungen innerhalb der Annotations-Begrenzungsbox bleiben.

v3.44.0 2026-05-21

AddSquareAnnotation erstellt eine Rechteck-Markup-Annotation (PDF /Subtype /Square) am angegebenen Rechteck, mit konfigurierbarer Rahmenbreite, Rahmenfarbe, optionaler Innenfüllfarbe, Deckkraft, Titel, Inhalt und Erstellungs-/Änderungszeitstempeln. Definiert in ISO 32000-1 §12.5.6.8. PDF 1.3 oder höher. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.
AddCircleAnnotation erstellt eine Ellipsen-Markup-Annotation (PDF /Subtype /Circle), die im angegebenen Rechteck eingeschrieben ist, mit denselben konfigurierbaren Rahmen, Füllung, Deckkraft, Titel, Inhalt und Zeitstempeln wie AddSquareAnnotation. Definiert in ISO 32000-1 §12.5.6.8. PDF 1.3 oder höher. Verfügbar in der Delphi-Bibliothek und den DLL-Schnittstellen.
Beide neuen Annotationen heben die Dokumentversion automatisch auf PDF 1.3 an, wenn sie unter einer niedrigeren Mindestversion-Sperre ausgegeben werden, und geben einen Standard-Markup-Annotations-Feldsatz aus (/Type /Subtype /Rect /C /IC /BS /Border /CA /F /M /CreationDate /NM /T /Contents /Subj /P), sodass bestehende Review-Workflows in Acrobat, Foxit und Edge sie nach der Erstellung weiterhin bearbeiten können.

v3.43.0 2026-05-20

SetStructElemSpaceBefore und SetStructElemSpaceAfter setzen die Attribute /SpaceBefore und /SpaceAfter (Layout-Owner) auf dem aktuell offenen Strukturelement und drücken den Abstand vor und nach Block-Elementen in Punkten aus. Definiert in ISO 32000-1 §14.8.5.4.2 Tabelle 340. Verfügbar in der Delphi-Bibliothek, ActiveX (Dispids 73008051/73008052) und DLL-Schnittstellen.
SetStructElemStartIndent und SetStructElemEndIndent setzen die Attribute /StartIndent und /EndIndent (Layout-Owner) und drücken den Einzug von den schreibrichtungsbewussten Start- und End-Kanten des Inhaltsrechtecks in Punkten aus. Definiert in ISO 32000-1 §14.8.5.4.2 Tabelle 340. Verfügbar in der Delphi-Bibliothek, ActiveX (Dispids 73008053/73008054) und DLL-Schnittstellen.
SetStructElemColor setzt das Attribut /Color (Layout-Owner) als RGB-Tripel (jede Komponente 0.0-1.0) und beschreibt die Vordergrundfarbe des Elements für Reflow-Engines und nachgelagerte Farbkontrast-Prüfer. Definiert in ISO 32000-1 §14.8.5.4.2 Tabelle 340. Verfügbar in der Delphi-Bibliothek, ActiveX (Dispid 73008055) und DLL-Schnittstellen.
Ein Serialisierungsfehler in BuildStructElemDictRef wurde behoben: Einzeltoken-numerische Attributwerte (wie SpaceBefore, SpaceAfter, StartIndent, EndIndent) wurden als PDF-Namen statt als PDF-Zahlen geschrieben. Die Korrektur gilt sowohl für Single-Owner- als auch für Multi-Owner-Attribut-Zweige.

v3.42.0 2026-05-20

CheckCompliancePDFA validiert nun korrekt alle sechs PDF/A-Modi (1a, 1b, 2a, 2b, 3a, 3b). Die PDFAID-Prüfung (Code 00005) akzeptiert jeden der sechs gültigen XMP-Marker statt nur '1B'. Die Versionsobergrenze-Prüfung (00002) wendet 1.4 für PDF/A-1 und 1.7 für PDF/A-2 und PDF/A-3 an.
Die OCProperties-Prüfung (Code 00003) ist nun bedingt: Sie gilt nur für PDF/A-1-Dokumente, wo optionaler Inhalt (Ebenen) verboten ist. PDF/A-2 und PDF/A-3 erlauben Ebenen und werden nicht mehr markiert.
Drei neue Compliance-Prüfungen hinzugefügt: Code 00006 markiert verschlüsselte Dokumente (Verschlüsselung ist in allen PDF/A-Versionen verboten); Code 00007 markiert Dokumente, denen ein OutputIntents-Eintrag im Katalog fehlt (erforderlich für alle PDF/A-Versionen); Codes 00011 und 00012 markieren Dokumente, denen MarkInfo oder StructTreeRoot fehlt, wenn die Konformitätsstufe -a (Barrierefreiheit) ist.

v3.41.0 2026-05-20

Der PDF/A-Modus erzwingt nun verbotene Operationen auf API-Ebene. Wenn ein PDF/A-Modus (einer von 1-6) aktiv ist, geben Aufrufe von SetEncryption, AddSeparationColor, SetFillColorCMYK, SetTextColorCMYK oder einer anderen CMYK/Separation/Shader-API 0 zurück und haben keine Wirkung, entsprechend der PDF/A-Anforderung eines einzigen sRGB-Output-Intents.
Transparenz ist in PDF/A-1 (Modi 1 und 2) verboten: SetTransparency, SetBlendMode und SetPageTransparencyGroup geben 0 zurück und sind no-ops, wenn der aktive Modus 1 oder 2 ist. PDF/A-2 und PDF/A-3 (Modi 3-6) erlauben begrenzte Transparenz und sind nicht eingeschränkt.
JavaScript-Aktionen sind in allen PDF/A-Modi (1-6) verboten: SetOpenActionJavaScript, PageJavaScriptAction, DocJavaScriptAction, AddGlobalJavaScript und AddLinkToJavaScript geben alle 0 zurück und sind no-ops, wenn ein PDF/A-Modus aktiv ist. ISO 19005-1 §6.6.1 verbietet JavaScript ausdrücklich in PDF/A-Dokumenten.
Datei-Anhang-APIs (EmbedFile, AddFileAttachment) sind in den PDF/A-1- und PDF/A-2-Modi (1-4) blockiert. Sie bleiben in PDF/A-3 (Modi 5 und 6) funktionsfähig, das ausdrücklich beliebige eingebettete Dateien erlaubt.

v3.40.0 2026-05-20

SetPDFAMode unterstützt nun die Konformitätsstufen PDF/A-2 und PDF/A-3. NewMode=3 für PDF/A-2b, 4 für PDF/A-2a, 5 für PDF/A-3b oder 6 für PDF/A-3a. PDF/A-2 zielt auf PDF 1.7 und erlaubt Ebenen, interaktive Formulare, JPEG2000-Bilder und begrenzte Transparenz. PDF/A-3 erweitert PDF/A-2, indem es beliebige eingebettete Dateien (jeden MIME-Typ) erlaubt. Alle -a-Varianten schreiben automatisch /MarkInfo und die markierten PDF-Strukturmarker, die für die Barrierefreiheitsstufe erforderlich sind.
Behoben: SetPDFAMode(1) (PDF/A-1a) war zuvor aufgrund eines internen Routing-Fehlers, der in v3.20.0 eingeführt wurde, ein no-op. Es schreibt nun korrekt /MarkInfo und /OutputIntents und setzt XMP pdfaid:part=1/conformance=A.
GetInformation(201) gibt '1' bis '6' zurück, passend zum aktiven PDF/A-Modus, in Übereinstimmung mit der neuen Modusnummerierung.

v3.39.0 2026-05-20

SetStructElemWritingMode setzt das Attribut /WritingMode (Layout-Owner) auf dem aktuell offenen Strukturelement. Gültige Werte sind LrTb (von links nach rechts, Standard für lateinische Schriften), RlTb (von rechts nach links, für Arabisch und Hebräisch) und TbRl (von oben nach unten, von rechts nach links, für traditionellen vertikalen CJK-Text). Definiert in ISO 32000-1 §14.8.5.4.2 Tabelle 340. Verfügbar in der Delphi-Bibliothek, ActiveX (Dispid 73008049) und DLL-Schnittstellen.
SetStructElemListNumbering setzt das Attribut /ListNumbering (List-Owner) auf dem aktuell offenen Strukturelement. Unterstützte Werte sind None, Disc, Circle, Square (ungeordnete Marker) und Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha (geordnete Nummerierung). Das Attribut wird auf das L-Element (List) gesetzt und ermöglicht es Hilfstechnologie, den Listentyp korrekt anzusagen. Definiert in ISO 32000-1 §14.8.5.3.2 Tabelle 336. Verfügbar in der Delphi-Bibliothek, ActiveX (Dispid 73008050) und DLL-Schnittstellen.

v3.38.0 2026-05-20

SetStructElemColSpan setzt das Attribut /ColSpan (Table-Owner) auf dem aktuell offenen Strukturelement und zeigt an, über wie viele Spalten die Zelle reicht. Definiert in ISO 32000-1 §14.8.5.7.2 Tabelle 337. Verfügbar in der Delphi-Bibliothek, ActiveX (Dispid 73008047) und DLL-Schnittstellen.
SetStructElemRowSpan setzt das Attribut /RowSpan (Table-Owner) auf dem aktuell offenen Strukturelement und zeigt an, über wie viele Zeilen die Zelle reicht. Definiert in ISO 32000-1 §14.8.5.7.2 Tabelle 337. Verfügbar in der Delphi-Bibliothek, ActiveX (Dispid 73008048) und DLL-Schnittstellen.
Beide Funktionen sind Komfort-Wrapper, äquivalent zum Aufruf von AddTagAttribute mit Owner='Table' und dem entsprechenden Attributnamen. Sie ergänzen SetStructElemScope für vollständig beschriebene Tabellenzellen in komplexen oder überspannenden Header-Tabellen.

v3.37.2 2026-05-20

GetPDFUADiagnostics meldet nun FORM-NO-TOOLTIP:N, wenn N interaktiven Formularfeldern (Widget-Annotationen) ein TU-Eintrag (Tooltip / barrierefreier Name) fehlt. ISO 14289-1 §7.18.4 verlangt, dass alle interaktiven Formularfelder einen TU-Eintrag tragen, damit Hilfstechnologie den Zweck des Felds dem Benutzer ansagen kann, wenn das Feld den Fokus erhält. /TU ist der barrierefreie Name, den Screenreader vorlesen; er unterscheidet sich von /T, das der partielle Feldname ist, der für programmatischen Zugriff und Formularübermittlung verwendet wird.

v3.37.1 2026-05-20

GetPDFUADiagnostics meldet nun LIST-STRUCT:N, wenn N LI- oder LBody-Strukturelemente außerhalb ihres erforderlichen Elternelements erscheinen. ISO 32000-1 §14.8.4.4 verlangt, dass LI ein direktes Kind von L (Liste) ist und LBody ein direktes Kind von LI (Listenelement). Eine fehlerhafte Listenverschachtelung verhindert, dass Hilfstechnologie Listeninhalt korrekt durchläuft und ansagt, und kann zu Validierungsfehlern der Dokumentstruktur in PDF/UA-1-Validatoren führen.

v3.37.0 2026-05-20

BeginTagEx2 ist eine neue API, die ein Strukturelement öffnet und alle Haupteigenschaften des Elements in einem einzigen Aufruf setzt. Zusätzlich zu den Parametern TagType, AltText, ActualText und Lang von BeginTagEx akzeptiert BeginTagEx2 Title (/T, für das Tags-Navigationspanel), ElemID (/ID, eindeutige Elementkennung) und Expansion (/E, vollständiger Text einer Abkürzung oder eines Akronyms). Ein leerer String für einen dieser drei zusätzlichen Parameter entspricht dem Weglassen des entsprechenden Setters. BeginTagEx2 reduziert den Boilerplate-Code für gut beschriebene Elemente — anstatt BeginTagEx gefolgt von SetStructElemTitle, SetStructElemID und SetStructElemExpansion separat aufzurufen, können alle sieben Eigenschaften in einem Aufruf gesetzt werden. Die Funktion ist in der Delphi-Bibliothek, ActiveX (Dispid 73008046) und DLL-Schnittstellen verfügbar.

v3.36.1 2026-05-20

GetPDFUADiagnostics meldet nun TABLE-TH-NO-SCOPE:N, wenn N TH-Strukturelementen (Tabellenkopfzellen) ein Scope-Attribut fehlt. ISO 32000-1 §14.8.4.3.4 Tabelle 337 definiert Scope (Row, Column oder Both) als das Attribut, das beschreibt, auf welche Datenzellen eine Kopfzelle zutrifft. Ohne es können Screenreader und andere Hilfstechnologien Kopfzellen nicht zuverlässig mit Datenzellen in komplexen oder Multi-Header-Tabellen verknüpfen, was von ISO 14289-1 §7.5 verlangt wird. Rufen Sie SetStructElemAttr('Table','Scope', 'Column') (oder 'Row' / 'Both') unmittelbar nach dem Tagging jedes TH-Elements auf.

v3.36.0 2026-05-20

SetStructElemExpansion ist eine neue API, die den /E-Eintrag (Erweiterungstext) auf dem aktuell offenen Strukturelement setzt (ISO 32000-1 §14.9.5). Der Erweiterungstext ist die vollständig ausgeschriebene Form einer Abkürzung oder eines Akronyms im Element — z. B. "World Wide Web" für ein Span, dessen Text "WWW" ist. Screenreader sprechen die Erweiterung aus, statt zu versuchen, die abgekürzten Zeichen auszusprechen, was für die Barrierefreiheit technischer und wissenschaftlicher Inhalte entscheidend ist. PDF/UA-1 (ISO 14289-1 §7.2) verlangt, dass die natürliche Sprache eindeutig bestimmbar ist; /E ist der Standardmechanismus für Abkürzungen und Akronyme. Die Funktion ist in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen verfügbar.

v3.35.1 2026-05-20

GetPDFUADiagnostics meldet nun DOCINFO-TITLE-MISSING, wenn der /Title-Eintrag des Dokumentinformations-Wörterbuchs fehlt oder leer ist. PDF/UA-1 (ISO 14289-1) verlangt einen Dokumenttitel, damit Screenreader ihn ansagen können, wenn das Dokument geöffnet wird. Die bestehende DISPLAYDOCTITLE-FALSE-Prüfung bestätigt, dass der Titel in der Viewer-Titelleiste angezeigt wird; DOCINFO-TITLE-MISSING ist komplementär — sie bestätigt, dass der Titelwert selbst gesetzt ist. Rufen Sie SetDocumentInfo('Title', ...) auf, um den Wert bereitzustellen.

v3.35.0 2026-05-20

SetStructElemTitle ist eine neue API, die den /T-Eintrag (Titel) auf dem aktuell offenen Strukturelement setzt (ISO 32000-1 §14.7.2 Tabelle 324). Der Titel ist eine für Menschen lesbare Bezeichnung, die die spezifische Elementinstanz identifiziert — zum Beispiel "Chapter 1", "Summary Table" oder "Figure 3: Quarterly Sales" — und wird im Tags-Navigationspanel von PDF-Viewern angezeigt und von Barrierefreiheits-Remediation-Tools verwendet. /T unterscheidet sich von /Alt (Alternativtext für Benutzer mit Renderbeeinträchtigungen) und /ActualText (Glyphen-Ebenen-Textkorrektur); es ist am nützlichsten bei nicht textuellen Container-Elementen wie Table, Figure, Form, Sect und Div. Übergeben Sie einen leeren String, um einen zuvor gesetzten Wert zu löschen. Die Funktion ist in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen verfügbar.

v3.34.0 2026-05-20

SetStructElemAltText ist eine neue API, die den /Alt-Eintrag auf dem aktuell offenen Strukturelement setzt (ISO 32000-1 §14.9.3). Sie ist äquivalent zur Übergabe von AltText an BeginTag, erlaubt aber, die Alternativtextbeschreibung zu setzen oder zu aktualisieren, nachdem das Element geöffnet wurde — nützlich, wenn die Beschreibung getrennt vom Elementtyp berechnet wird. PDF/UA-1 (ISO 14289-1 §7.5) verlangt Alt-Text auf Figure- und Formula-Elementen; GetPDFUADiagnostics meldet bereits FIGURE-NO-ALT:N für fehlende Werte. Die Funktion ist in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen verfügbar.

v3.33.1 2026-05-20

GetPDFUADiagnostics enthält nun eine ROLEMAP-UNMAPPED:N-Prüfung, die benutzerdefinierte Strukturelementtyp-Namen erkennt, die im Dokument verwendet werden und keinen Eintrag im /RoleMap-Wörterbuch haben. ISO 14289-1 §7.1 und ISO 32000-1 §14.7.3 verlangen, dass jeder nicht standardmäßige Strukturtyp einem standardmäßigen PDF-Typ (wie P, Span oder Figure) zugeordnet wird, damit Hilfstechnologie bestimmen kann, wie das Element zu behandeln ist. Wenn N nicht zugeordnete Typen gefunden werden, enthält die Issue-Beschreibung die Liste der Typnamen, sodass Aufrufer wissen, welche AddRoleMap-Einträge benötigt werden. Alle 49 standardmäßigen Strukturtypen, die in ISO 32000-1 Tabelle 333 (PDF 1.7) definiert sind, werden erkannt und vom Bericht ausgeschlossen.

v3.33.0 2026-05-20

SetStructElemLang ist eine neue API, die den /Lang-Eintrag auf dem aktuell offenen Strukturelement setzt (ISO 32000-1 §14.9.2). Das Sprach-Tag überschreibt die dokumentebene Sprache, die von SetDocumentLanguage oder SetPDFUAMode deklariert wurde, für das Element und alle seine Nachkommen, was es mehrsprachigen Dokumenten ermöglicht, jede Spanne mit ihrem korrekten BCP 47-Sprach-Tag (z. B. 'en-US', 'fr', 'zh-Hant-TW') zu markieren. Screenreader verwenden das elementebene /Lang, um die geeignete Text-to-Speech-Engine oder Stimme zu wählen, wenn das Dokument vorgelesen wird. Die Funktion ist in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen verfügbar.

v3.32.0 2026-05-20

SetStructElemActualText ist eine neue API, die den /ActualText-Eintrag auf dem aktuell offenen Strukturelement setzt (ISO 32000-1 §14.9.4). Verwenden Sie sie, um den genauen Unicode-Text anzugeben, den eine Glyphensequenz repräsentiert, wenn die Inhaltsstrom-Extraktion zu falschen Ergebnissen führen würde — die häufigsten Fälle sind OpenType-Ligaturglyphen (U+FB00 ff, U+FB01 fi, U+FB02 fl) und Abkürzungen mit nicht offensichtlichen Erweiterungen. ActualText ergänzt den gerenderten Inhalt, ersetzt ihn aber nicht; es überschreibt, was Hilfstechnologie und Textextrahierer für dieses Element vorlesen, ohne das visuelle Rendering zu unterdrücken. Die Funktion ist in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen verfügbar.

v3.31.1 2026-05-20

GetPDFUADiagnostics prüft nun zusätzlich zu Figure-Elementen auch Formula-Strukturelemente, wenn fehlender Alt-Text gemeldet wird (FIGURE-NO-ALT:N). ISO 32000-1 §14.9.3 verlangt alternative Beschreibungen für sowohl grafische Figuren als auch mathematische Formeln; zuvor wurden nur Figure-Elemente gescannt.
GetPDFUADiagnostics meldet nun PDF-VERSION-LOW, wenn die PDF-Version des Dokuments unter 1.7 liegt. PDF/UA-1 (ISO 14289-1) ist gegen PDF 1.7 (ISO 32000-1:2008) definiert; Dokumente auf PDF 1.5 oder 1.6 erfüllen die Grundanforderungen der Spezifikation nicht. Rufen Sie SetPDFUAMode auf, um die Version automatisch auf 1.7 anzuheben.

v3.31.0 2026-05-19

Strukturelement-IDs und Tabellenkopf-Verknüpfungen werden nun unterstützt. SetStructElemID weist dem aktuell offenen Strukturelement eine eindeutige String-Kennung (/ID) zu; IDs werden beim Speichern des Dokuments in einen /IDTree-Namensbaum auf der Strukturbaumwurzel gesammelt, was Barrierefreiheits-Tools und Querverweise ermöglicht, Elemente per ID zu finden (ISO 32000-1 §14.7.4). SetStructElemHeaders verknüpft die aktuelle Tabellenzelle (TD oder TH) mit einer oder mehreren Kopfzellen über eine kommagetrennte Liste zuvor zugewiesener IDs und schreibt das /Headers-Array im Table-Attribut-Owner-Wörterbuch (ISO 32000-1 §14.8.5.7.2). Zusammen unterstützen diese beiden Funktionen komplexe Tabellenmarkierung für PDF/UA-1 (ISO 14289-1 §7.10) und WCAG 2.x SC 1.3.1. Beide Funktionen sind in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen verfügbar. AddTagAttribute behandelt nun auch das /Headers-Attribut mit kommagetrennten Werten, die als PDF-Textzeichenketten-Arrays geschrieben werden, korrekt.

v3.30.1 2026-05-19

GetPDFUADiagnostics enthält nun eine HEADING-LEVEL-SKIP:N-Prüfung, die Überschriftenebenen-Sprünge in Dokumentreihenfolge erkennt (z. B. ein H1 unmittelbar gefolgt von einem H3 ohne H2 dazwischen). Die Prüfung führt eine Vorordnungs-Traversierung des gesamten Strukturelementbaums durch und zählt jedes Vorkommen, bei dem die nächste Überschriftenebene die vorherige um mehr als eins überschreitet. Generische H-Elemente werden als H1 behandelt. Zurück zu einer höheren Überschriftenebene zu gehen (H3 → H1) wird nicht als Sprung gezählt. WCAG 2.x Erfolgskriterium 1.3.1 und ISO 14289-1 §7.1 verlangen, dass Überschriften ohne Lücken verschachtelt sind.

v3.30.0 2026-05-19

Strukturelement-Attribute werden nun für markierte PDF- und PDF/UA-Dokumente unterstützt. Drei neue API-Funktionen erlauben das Anhängen von Attributen an das Strukturelement, das gerade auf dem Tag-Stack erstellt wird: AddTagAttribute (allgemein, beliebige Owner/Name/Wert), SetStructElemScope (Komfort-Wrapper, der das /Scope-Attribut unter dem Table-Owner setzt, für TH-Kopfzellen — ISO 32000-1 §14.8.5.7.2) und SetStructElemBBox (Komfort-Wrapper, der das /BBox-Attribut unter dem Layout-Owner setzt, für Figuren und andere visuell positionierte Elemente — ISO 32000-1 §14.8.5.4). Beim Speichern des Dokuments werden Attribute als /A-Attribut-Wörterbücher in jedem Strukturelement geschrieben; mehrere Attribute desselben Owners werden in einem Wörterbuch gruppiert, und Attribute verschiedener Owner werden als Array von Wörterbüchern geschrieben. Alle drei Funktionen sind in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen verfügbar.

v3.29.1 2026-05-19

GetPDFUADiagnostics enthält nun zwei zusätzliche Prüfungen: ob Figure-Strukturelemente im Dokument einen Alt-Textwert vermissen (gemeldet als FIGURE-NO-ALT:N, gemäß ISO 14289-1 §7.5 und ISO 32000-1 §14.9.3) und ob Strukturelemente noch offen sind, weil EndTag nicht aufgerufen wurde (gemeldet als STRUCT-UNCLOSED:N). Die Figur-Prüfung führt einen vollständigen rekursiven Durchlauf des Strukturelementbaums durch und deckt Elemente in allen Verschachtelungstiefen ab.

v3.29.0 2026-05-19

GetPDFUADiagnostics ist eine neue Diagnose-API, die ein Dokument auf potenzielle PDF/UA-1 (ISO 14289-1)-Konformitätsprobleme prüft und eine durch Zeilenumbruch getrennte Liste von Ergebnissen zurückgibt. Sechs Prüfungen werden durchgeführt: ob MarkInfo/Marked gesetzt ist (markierte PDF), ob der Dokumentkatalog einen /Lang-Eintrag hat, ob ViewerPreferences/DisplayDocTitle true ist, ob die XMP-Metadaten einen pdfuaid:part-Bezeichner enthalten, die Anzahl der nicht ausgenommenen Annotationen, denen ein Contents-Eintrag fehlt, und die Anzahl der eingebetteten Dateien, denen ein AFRelationship-Eintrag fehlt. Jedes Ergebnis wird durch einen kurzen Code (z. B. LANG-MISSING, ANNOT-NO-CONTENTS:3) gefolgt von einer für Menschen lesbaren Beschreibung identifiziert. Gibt einen leeren String zurück, wenn keine Probleme gefunden werden. Verfügbar in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen.

v3.28.5 2026-05-19

PDF/UA-1-Annotations-Barrierefreiheitsverbesserung: Wenn eine FileAttachment-Annotation keinen Contents-Eintrag und kein /T-Feld hat, wird nun der Dateiname aus der eingebetteten Dateispezifikation der Annotation (/FS /UF oder /F) als Fallback-Barrierefreiheitsbeschreibung verwendet. Dies vervollständigt die Annotations-Contents-Fallback-Kette: /T → Link-URI → Stamp-Name → FileAttachment-Dateiname. Screenreader erhalten den Namen der angehängten Datei statt Stille, was ISO 14289-1 §7.18.1 für die häufigsten Annotationstypen erfüllt.

v3.28.4 2026-05-19

PDF/UA-1-Annotations-Barrierefreiheitsverbesserung: Wenn eine Stamp-Annotation keinen Contents-Eintrag (oder einen leeren) und kein /T-Feld hat, wird nun der Stempeltypname aus dem /Name-Eintrag der Annotation als Fallback-Barrierefreiheitsbeschreibung verwendet (z. B. "Approved", "Draft", "Confidential", "Final"). Dies erweitert die in v3.28.3 eingeführte Annotations-Contents-Fallback-Kette, um Stempel-Annotationen abzudecken, die in Workflows mit geprüften oder genehmigten Dokumenten häufig sind und häufig keinen expliziten Contents-Wert haben.

v3.28.3 2026-05-19

PDF/UA-1-Annotations-Barrierefreiheitsverbesserung: Wenn eine Link-Annotation keinen Contents-Eintrag (oder einen leeren) und kein /T-Feld hat, wird nun die URI aus der URI-Aktion der Annotation als Fallback-Barrierefreiheitsbeschreibung verwendet. Dies gilt nur während der SetPDFUAMode-Verarbeitung und nur für Link-Annotationen, die eine /URI-Aktion tragen. Screenreader erhalten die URL als letzte Notfall-Bezeichnung, was ISO 14289-1 §7.18.1 in dem häufigen Fall erfüllt, in dem Autoren Hyperlinks ohne eine für Menschen lesbare Beschreibung erstellen.

v3.28.2 2026-05-19

SetEmbeddedFileAFRelationship ist eine neue API zum expliziten Setzen des AFRelationship-Werts im Dateispezifikations-Wörterbuch einer eingebetteten Datei. Erforderlich von ISO 14289-1 (PDF/UA-1) §7.11, erlaubt dies Aufrufern, die semantische Beziehung einer eingebetteten Datei zum Dokumentinhalt anzugeben, indem sie aus den fünf gültigen Werten wählen: Source, Data, Alternative, Supplement oder Unspecified. Wenn SetPDFUAMode aktiv ist, wird jeder eingebetteten Datei ohne AFRelationship-Schlüssel automatisch Unspecified zugewiesen; verwenden Sie diese Funktion, um diesen Standardwert vor dem Speichern zu überschreiben. Verfügbar in der Delphi-Bibliothek, ActiveX und DLL-Schnittstellen.

v3.28.1 2026-05-19

Wenn SetPDFUAMode auf einem Dokument aufgerufen wird, dessen XMP-Metadaten den generischen Bibliotheks-Standardtitel statt eines dokumentspezifischen tragen, wird der Titel nun automatisch durch den Wert aus dem /Info Title-Eintrag des Dokuments ersetzt (falls vorhanden). Dies stellt sicher, dass das pdfuaid:part-1-XMP-Paket den tatsächlichen Dokumenttitel statt eines Platzhalters widerspiegelt, was die Erwartungen von PDF/UA-1-Verifizierern erfüllt.
Der XMP-Parser (LoadFromString) liest nun den dc:title-Wert aus vorhandenen XMP-Metadaten, wenn ein Dokument geladen wird, sodass das Round-Tripping einer PDF, die bereits dc:title hat, diesen Titel korrekt beibehält, statt zum Standard-Platzhalter zurückzukehren.

v3.28.0 2026-05-19

BeginArtifactEx(ArtifactType, ArtifactSubtype) ist eine neue Tagged-PDF-API, die BeginArtifact erweitert, um sowohl den Artifact-/Type als auch den Pagination-/Subtype in einem einzigen Aufruf auszudrücken. Wenn beide Parameter nicht leer sind, lautet der geschriebene Operator /Artifact << /Type /T /Subtype /S >> BMC und ermöglicht vollständig spezifizierte Pagination-Artifacts wie Kopf- und Fußzeilen gemäß ISO 32000-1 §14.8.2.2.1. Wenn nur ein Parameter nicht leer ist, wird die entsprechende Einzelschlüsselform verwendet. DLL-Einstiegspunkte DLBeginArtifactEx und DLBeginArtifactExA werden ebenfalls exportiert.

v3.27.2 2026-05-19

BeginArtifact unterscheidet nun korrekt zwischen Artifact-Typen und Pagination-Subtypen. Wenn das Argument Pagination, Layout oder Page ist (Artifact-Typen gemäß ISO 32000-1 §14.8.2.2.1 Tabelle 330), schreibt der Marked-Content-Operator /Type statt /Subtype. Andere Werte wie Header, Footer und Watermark werden weiterhin als /Subtype geschrieben. Dies korrigiert die zuvor falsche Ausgabe, die /Subtype /Pagination schrieb, wenn der Aufrufer beabsichtigte, ein Pagination-Artifact zu markieren.

v3.27.1 2026-05-19

Wenn der PDF/UA-Modus aktiv ist und das Dokument eingebettete Dateien enthält, erhält jedes Dateispezifikations-Wörterbuch, dem ein AFRelationship-Eintrag fehlt, diesen nun automatisch beim Speichern. Der geschriebene Wert ist /Unspecified, was die ISO 14289-1 §7.11-Anforderung erfüllt, dass jede eingebettete Datei einen AFRelationship-Schlüssel trägt. Dies gilt sowohl für über EmbedFile hinzugefügte Dateien als auch für eingebettete Dateien, die bereits in einem geladenen Dokument vorhanden sind.

v3.27.0 2026-05-19

AddRoleMap(CustomType, StandardType) ist eine neue Tagged-PDF-API, die eine Zuordnung von einem benutzerdefinierten (nicht standardmäßigen) Strukturelementtyp-Namen zu einem standardmäßigen PDF-Strukturtyp registriert. Beim Speichern werden die Zuordnungen in das RoleMap-Wörterbuch in der Strukturbaumwurzel geschrieben, was die Anforderung von ISO 14289-1 §7.1 für Dokumente erfüllt, die anwendungsspezifische Tag-Namen verwenden. Mehrere Zuordnungen können registriert werden; doppelte Schlüssel werden vom letzten Aufruf überschrieben. DLL-Einstiegspunkte DLAddRoleMap und DLAddRoleMapA werden ebenfalls exportiert.

v3.26.0 2026-05-19

BeginTagEx(TagType, AltText, ActualText, Lang) ist eine neue Tagged-PDF-API, die BeginTag um ein explizites Attribut für die natürliche Sprache erweitert. Wenn Lang nicht leer ist, wird es in das /Lang-Attribut des Strukturelements geschrieben, was die elementweise Sprachannotation ermöglicht, die von ISO 14289-1 §7.2 für mehrsprachige Dokumente verlangt wird. Ein leerer Lang-String führt zum gleichen Verhalten wie BeginTag. DLL-Einstiegspunkte DLBeginTagEx und DLBeginTagExA werden ebenfalls exportiert.

v3.25.1 2026-05-19

Nicht-subset TrueType-Schriften, die mit der Standard-Windows-Codepage (WinAnsiEncoding) geladen wurden, erhalten nun einen ToUnicode-CMap-Stream, was zuverlässige Unicode-Textextraktion und Kopieren/Einfügen für diese Schriften ermöglicht. Zuvor wurde ein ToUnicode-Stream nur geschrieben, wenn eine explizite Codepage-Überschreibung oder ein Differences-Array vorhanden war; der häufige Standardcodierungspfad hatte ihn vermisst.
Die gleiche Korrektur gilt für TrueType-Schriften, die mit einer expliziten nicht-standardmäßigen Codepage, aber ohne Differences-Array geladen wurden, und für Schriften, die über das verpackte Schriftformat geladen wurden.

v3.25.0 2026-05-19

Wenn der PDF/UA-Modus aktiv ist, erhalten nicht ausgenommene Annotationen (alle Typen außer Widget, PrinterMark und TrapNet), denen ein nicht leerer Contents-Eintrag fehlt, diesen nun automatisch beim Speichern. Der /T (Titel / Autor)-Wert der Annotation wird als Fallback verwendet, was ISO 14289-1 §7.18.1 für Annotationen erfüllt, die einen Titel, aber keine explizite Barrierefreiheitsbeschreibung tragen.

v3.24.0 2026-05-19

Wenn der PDF/UA-Modus aktiv ist, erhalten interaktive Formularfelder, denen ein TU (Tooltip / Alternativbeschreibung)-Eintrag fehlt, diesen nun automatisch beim Speichern. Der partielle Name (/T-Eintrag) des Felds wird als Fallback-Wert verwendet, was sicherstellt, dass Screenreader jedes Feld identifizieren können. Druckknöpfe werden gemäß ISO 14289-1 §7.18.4 korrekt von dieser Anforderung ausgeschlossen.

v3.23.1 2026-05-19

GetInformation(200) gibt '1' zurück, wenn der PDF/UA-1-Modus auf dem ausgewählten Dokument aktiv ist, sodass Aufrufer den Konformitätsmodusstatus zur Laufzeit abfragen können.
GetInformation(201) gibt '1' für PDF/A-1a, '2' für PDF/A-1b oder einen leeren String zurück, wenn der PDF/A-Modus aus ist.
GetInformation(311) und GetInformation(312) geben nun den Versionsanforderungsstring und Funktionsnamen aus dem jüngsten Versionssperr-Konflikt korrekt zurück (zuvor im v3.20.3-Eintrag angekündigt, aber noch nicht implementiert).
GetInformation(313) gibt den PDF-Versionsstring zurück, auf den das Speicherziel derzeit gesperrt ist, oder einen leeren String für frei versionierte Dokumente.

v3.23.0 2026-05-19

SetMarkInfo(Marked) ist nun eine öffentliche API, die es erlaubt, das MarkInfo.Marked-Flag unabhängig von der vollständigen PDF/UA-1-Einrichtung zu setzen, die von SetPDFUAMode durchgeführt wird. Wenn Marked 1 ist, wird MarkInfo.Suspects gemäß ISO 14289-1 §7.18.6 ebenfalls auf false gesetzt.
Wenn der PDF/UA-Modus aktiv ist, erhalten alle Seiten automatisch einen /Tabs /S-Eintrag beim Speichern, was die strukturbasierte Tab-Reihenfolge-Anforderung von ISO 14289-1 §7.18.4 erfüllt.
HTML-Referenzdokumentation für SetPDFUAMode, SetDocumentLanguage, SetMarkInfo, BeginTag, EndTag, BeginArtifact und EndArtifact hinzugefügt, mit vollständigen Syntaxtabellen und Verwendungsbeispielen.

v3.22.0 2026-05-19

BeginTag(TagType, AltText, ActualText) öffnet ein markiertes PDF-Strukturelement im aktuellen Inhaltsstrom, schreibt einen BDC-Operator mit automatisch zugewiesener MCID und registriert das Element im Dokumentstrukturbaum. TagType ist ein beliebiger PDF-Standard-Strukturtyp (P, H1, Figure, Table usw.). AltText und ActualText sind optionale Barrierefreiheitsstrings, die als PDF-Textstrings (UTF-16BE) codiert sind.
EndTag schließt das zuletzt geöffnete Strukturelement und schreibt den passenden EMC-Operator in den Inhaltsstrom.
BeginArtifact(SubType) markiert eine Inhaltsregion als PDF-Artifact (Pagination-Artefakt, Hintergrund usw.) und schreibt einen BMC-Operator. SubType ist optional; wenn angegeben, wird er als /Artifact << /Subtype /SubType >> geschrieben.
EndArtifact schließt die Artifact-Region mit einem EMC-Operator.
Beim Speichern, wenn markierte Strukturelemente registriert wurden, baut die Bibliothek automatisch den vollständigen StructTreeRoot auf, weist betroffenen Seiten StructParents-Schlüssel zu und schreibt den ParentTree-Zahlenbaum, was die Anforderungen von ISO 32000-1 §14.7 für markiertes PDF erfüllt.
Standard-Type-1-Schriften (Helvetica, Times, Courier-Familie, Symbol) und eingebettete Type-1-Schriften mit WinAnsi-Codierung erhalten nun einen ToUnicode-CMap-Stream, was zuverlässige Unicode-Textextraktion und Kopieren/Einfügen für diese Schrifttypen ermöglicht.

v3.21.0 2026-05-19

SetPDFUAMode(Language) aktiviert den PDF/UA-1 (ISO 14289-1)-Konformitätsmodus: hebt das Dokument automatisch auf PDF 1.7 an, schreibt MarkInfo.Marked und MarkInfo.Suspects, aktiviert DisplayDocTitle in ViewerPreferences, setzt Catalog.Lang, wenn Language nicht leer ist, und schreibt den von ISO 14289-1 Abschnitt 6.7.11 geforderten pdfuaid:part = 1 XMP-Namespace-Eintrag.
SetDocumentLanguage(Language) schreibt direkt den Catalog /Lang-Eintrag und ermöglicht es, die Dokumentsprache unabhängig vom PDF/UA-Modus zu deklarieren.
MarkInfo.Suspects wird nun auf false gesetzt, wann immer MarkInfo.Marked auf true gesetzt ist, was die markierte PDF-Strukturanforderung von ISO 14289-1 (Abschnitt 7.18.6) erfüllt.
Encrypt erzwingt nun das CanCopyAccess (Inhaltskopieren für Barrierefreiheit)-Berechtigungsflag, wenn das Dokument im PDF/UA-Modus ist, wie von ISO 14289-1 Abschnitt 7.17 verlangt.
Choice (Dropdown)-Formularfelder tragen keinen bedeutungslosen hartcodierten Tooltip-Wert mehr; TU bleibt ungesetzt, sodass der Aufrufer über die Formularfeld-Eigenschafts-API eine sinnvolle Bezeichnung zuweisen kann.

v3.20.3 2026-05-19

Encrypt und AddSWFAnnotationFromFile geben nun sofort 0 mit LastErrorCode 602 zurück, wenn die Speicherversion unter dem von der ausgewählten Verschlüsselungsstärke oder dem Annotationstyp geforderten Minimum gesperrt ist, statt stillschweigend fortzufahren und erst beim Speichern zu scheitern.
GetInformation(311) und GetInformation(312) spiegeln nun die widersprüchliche Versionsanforderung zum Schreibzeitpunkt wider, wenn eine gesperrte Version Funktionen auf Erweiterungsebene wie AES-256 oder RichMedia-Annotationen blockiert.

v3.20.2 2026-05-19

AddU3DAnnotationFromFile hebt die Dokumentversion nun automatisch auf PDF 1.6 an, wenn eine 3D-Annotation einem Dokument mit niedrigerer Version hinzugefügt wird, konsistent mit dem Version-Auto-Bump-Verhalten aller anderen PDF 1.6+ API-Einstiegspunkte.

v3.20.1 2026-05-17

PDF 1.2-Speicherziele werden nun als strenge PDF 1.2-Verträge durchgesetzt. Das Speichern von PDF 1.3+-Objekten wie Page TrimBox-Daten unter einem PDF 1.2-Ziel scheitert vor dem Schreiben der Ausgabe, statt eine gemischtversionierte Datei auszugeben.
Die PDF 1.7 Adobe-Erweiterungsebenen-Konformität ist nun Teil der Speicher-Prüfung. AESV3, AES-256, RichMedia, Projection, geospatial-Wörterbücher und ETSI-Signatur-Subfilter werden gegen den geforderten ExtensionLevel geprüft.
AES-256-Verschlüsselung, RichMedia-Annotationen, geospatial-Wörterbücher und ETSI-Signatur-Subfilter deklarieren nun den passenden Adobe Extensions-Eintrag, wenn PDFlib ein Dokument automatisch auf PDF 1.7-Erweiterungsinhalt anhebt.
Append-Speichern verwenden nun dasselbe Versionskonformitäts-Gate wie vollständige Speichern.
Mitgelieferte optionale PDFium-Laufzeit-DLLs wurden für Win32 und Win64 aktualisiert. GDI+ bleibt der Standard-Renderer; PDFium bleibt opt-in über SetPDFiumFileName und SelectRenderer(3).
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 207/207, und C++Builder Win64x GoogleTest bestand 61 Tests mit 2 vorhandenen sample-abhängigen Tests übersprungen.

v3.20.0 2026-05-17

Acht weitere PDFlib-Writer-Einstiegspunkte werden nun durch Phase 3 EnsureMinVersion geleitet, sodass die Dokumentversion automatisch auf das von der emittierten Funktion geforderte Minimum angehoben wird: SetDocumentMetadata (PDF 1.4 - /Metadata XMP-Stream), SetPDFAMode(1 oder 2) (PDF 1.4 - /MarkInfo + /OutputIntents), PageJavaScriptAction (PDF 1.5 - Page /AA + JavaScript), DocJavaScriptAction (PDF 1.4 - Catalog /AA + JavaScript), SetTabOrderMode (PDF 1.5 - Page /Tabs), NewOptionalContentGroup (PDF 1.5 - /Type /OCG), SetNeedAppearances (PDF 1.5 - AcroForm /NeedAppearances), NewFormField(ftSignature) (PDF 1.5 - AcroForm /SigFlags AppendOnly).
In Kombination mit dem v3.15.0-Set (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout) und dem v3.17.0-Set (acht JavaScript- / Datei-Anhang- / XFA- / SWF-Einträge) hebt PDFlib FVersion nun automatisch über einundzwanzig Writer-Einstiegspunkte hinweg an.
NewOptionalContentGroup hob FVersion zuvor direkt an; es geht nun durch EnsureMinVersion, sodass LockSaveVersion berücksichtigt wird und der Bump in AutoBumpedFeatures aufgezeichnet wird.

v3.19.0 2026-05-17

Die Speicher- und Ladezeit-PDF-Versionskonformität erkennt nun auch vier zuvor zurückgestellte Funktionen: Btn /Ff Bit 15 NoToggleToOff (nur Radio-Button) -> PDF 1.4, DeviceN /Subtype /NChannel (Farbraum-Verfeinerung) -> PDF 1.6, FontFile3 /Subtype /OpenType (Schriftprogrammtyp) -> PDF 1.6, Sig /SubFilter ETSI.CAdES.detached oder ETSI.RFC3161 -> PDF 1.7.
Die NChannel-Regel stimmt mit der DeviceN-Farbraum-Array-Form [/DeviceN names alternateSpace tintTransform attributes] überein, wenn das attributes-Wörterbuch an Index 4 /Subtype /NChannel trägt.
Die FontFile3 OpenType-Regel wird nur ausgelöst, wenn der Stream über einen Eltern-Schlüssel namens 'FontFile3' erreicht wird, sodass nicht verwandte Streams, die zufällig /Subtype /OpenType tragen, nicht markiert werden.
Die PDFFeatureRules-Tabelle enthält nun 103 Regeln (99 + 4 neu).

v3.18.6 2026-05-17

Die Speicher- und Ladezeit-PDF-Versionskonformität erkennt nun /AA (zusätzliche Aktionen) mit Container-Typ-Bewusstsein: Catalog /AA (Trigger auf Dokumentebene) -> PDF 1.4, Annot /AA (Annotations-Trigger) -> PDF 1.4, Page /AA (Seiten-Trigger) -> PDF 1.5.
Formularfeld-/AA (PDF 1.2) bleibt vom bestehenden PDF 1.3-Speichervertrag abgedeckt; keine Regel nötig.
Die PDFFeatureRules-Tabelle enthält nun 99 Regeln (96 + 3 neu).

v3.18.5 2026-05-17

Die Speicher- und Ladezeit-PDF-Versionskonformität klassifiziert Page /Tabs nun korrekt als PDF 1.5-Funktion; zuvor war es als PDF 1.4 fehlklassifiziert. Das PDF 1.4-Spezifikations-Änderungsdokument (Adobe TN #5409) listet /Tabs nicht auf, und PDF 1.5 Tabelle 8.10 führt "Tabs (Optional; PDF 1.5)" ein.
Neue Regel: AcroForm /NeedAppearances wird gemäß PDF 1.5 Tabelle 218 als PDF 1.5-Funktion erkannt.
Die PDFFeatureRules-Tabelle enthält nun 96 Regeln (95 + 1 neu).

v3.18.4 2026-05-13

PDFlibZLib verwendet nun immer das mitgelieferte statische zlib-ng-Objekt-Backend bei normalen Bibliotheks-Builds und entfernt den verbleibenden System.ZLib-Fallback-Pfad.
Die zlib-ng-Regressionsabdeckung umfasst nun grenzgröße Nutzlasten, PNG-ähnliche Scanline-Daten, gespeicherte Multi-Block-Streams und bekannte zlib-Streams über Delphi- und C++Builder-Test-Runner.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 194/194, und C++Builder Win64x GoogleTest bestand 58 Tests mit 2 vorhandenen sample-abhängigen Tests übersprungen.

v3.18.3 2026-05-12

Delphi- und C++Builder-Demos, die PDF- oder Textausgabe generieren, öffnen das generierte Dokument nun automatisch nach erfolgreichem Speichern.
Die Installer-Paketierung hält Build-Artefakte nun von Demo-Ordnern fern und macht C++Builder-Beispiele plus DLL- und ActiveX/OCX-Module zu opt-in-Komponenten; ihre passenden Dateien werden nur installiert, wenn die Komponente ausgewählt ist.

v3.18.2 2026-05-12

Die Delphi- und C++Builder EditFormField-Demos löschen nun /NeedAppearances vor dem Aktualisieren der Feldwerte, sodass jedes bearbeitete Textfeld einen aktualisierten normalen Erscheinungs-Stream in der gespeicherten PDF erhält.
Dies hält den gespeicherten /AP-Stream mit dem gespeicherten /V-Wert synchron und vermeidet viewerabhängige Unterschiede, bei denen das Fokussieren des Felds Text enthüllt, der im statischen Felderscheinungsbild fehlte.

v3.18.1 2026-05-10

Die Speicher- und Ladezeit-PDF-Versionskonformität erkennt nun auch bitweise Formularfeld-/Ff-Flags und das AcroForm /SigFlags AppendOnly-Bit: /Ff Bit 21 (FileSelect, Maske 1048576) -> PDF 1.4, /Ff Bit 22 (MultiSelect, Maske 2097152) -> PDF 1.4, /Ff Bit 23 (DoNotSpellCheck, Maske 4194304) -> PDF 1.4, /Ff Bit 24 (DoNotScroll, Maske 8388608) -> PDF 1.4, /Ff Bit 25 (Comb, Maske 16777216) -> PDF 1.5, /Ff Bit 26 (RichText / RadiosInUnison, 33554432) -> PDF 1.5, /Ff Bit 27 (CommitOnSelChange, Maske 67108864) -> PDF 1.5, /SigFlags Bit 2 (AppendOnly, Maske 2) -> PDF 1.5.
Die /Parent-Vererbung wird nicht verfolgt: nur Wörterbücher, die explizit /Ff oder /SigFlags tragen, lösen die Regeln aus.
Die PDFFeatureRules-Tabelle enthält nun 95 Regeln (87 + 8 neue bitweise).
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 191/191, und C++Builder Win64x GoogleTest bestand 57/57.

v3.18.0 2026-05-10

Die Speicher- und Ladezeit-PDF-Versionskonformität erkennt nun neun weitere Unterschlüssel- und bitweise Funktionen: bitweise Annotationsflags (/F-Maske): Locked (128) -> PDF 1.4, ToggleNoView (256) -> PDF 1.5, LockedContents (512) -> PDF 1.7. Unterscheidbare Katalog- und Seiten-Unterschlüssel: /BoxColorInfo (Seite) -> PDF 1.4, /Permissions, /Legal, /PresSteps -> PDF 1.5, /VP (Seiten-Geospatial-Viewport) -> PDF 1.6, /Collection (Katalog Portable Collection) -> PDF 1.7.
Die PDFFeatureRules-Tabelle enthält nun 87 Regeln (78 auf Kapitelebene + 9 Unterschlüssel / bitweise).
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 189/189, und C++Builder Win64x GoogleTest bestand 57/57.

v3.17.0 2026-05-10

Acht weitere PDFlib-Writer-Einstiegspunkte werden nun durch Phase 3 EnsureMinVersion geleitet, sodass die Dokumentversion automatisch auf das von der emittierten Funktion geforderte Minimum angehoben wird: AddLinkToJavaScript, SetOpenActionJavaScript, AddGlobalJavaScript, FormFieldJavaScriptAction (PDF 1.3 - JavaScript-Aktionen), AddEmbeddedFile, AddFileAttachment (PDF 1.3 - Datei-Anhänge), SetXFAFromString (PDF 1.5 - XFA-Formulare), AddSWFAnnotationFromFile (PDF 1.7 - RichMedia-Annotation).
In Kombination mit dem v3.15.0-Set (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout) deckt PDFlib nun 13 hochversionierte Writer-Einstiegspunkte durchgängig ab.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 187/187, und C++Builder Win64x GoogleTest bestand 57/57.

v3.16.3 2026-05-10

Neue PDFlib-API: LockSaveVersion(Version) heftet das Dokument an Version und verhindert, dass Phase 3 writerseitig EnsureMinVersion automatisch darüber hinaus anhebt. UnlockSaveVersion löscht die Sperre.
Das Speicherzeit-Gate ist unverändert: Writer-emittierte Funktionen über der gesperrten Version erzeugen weiterhin LastErrorCode 602 beim Speichern, statt den Header stillschweigend anzuheben.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 184/184, und C++Builder Win64x GoogleTest bestand 57/57.

v3.16.2 2026-05-10

Geladene PDFs zeigen nun eine Beitragsleisten-Ansicht der Ladezeit-Funktions-Erkennung über GetInformation(103) ("ContributorFeatures"). Die Liste enthält nur Funktionen, deren minimal erforderliche Version strikt größer als HeaderVersion (Schlüssel 100) ist, sodass sie direkt die Frage beantwortet: "Warum ist die effektive Version höher als der Datei-Header?".
GetInformation(101) ("DetectedFeatures") ist unverändert und listet weiterhin jede passende Funktion auf, unabhängig vom Beitrag.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 181/181, und C++Builder Win64x GoogleTest bestand 57/57.

v3.16.1 2026-05-10

Erweiterte ladeseitige Erkennungstestabdeckung mit sechs zusätzlichen synthetischen Fixtures: seiteninterner Transparenz-ExtGState (kein Versions-Bump), Catalog /MarkInfo (PDF 1.3 -> PDF 1.4), /OCProperties + OCG-Inhalt (PDF 1.4 -> PDF 1.5), /Type /3DStream (PDF 1.5 -> PDF 1.6), eine Multi-Feature-Kombinations-Fixture und eine Snapshot-Stabilitätsprüfung.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 179/179, und C++Builder Win64x GoogleTest bestand 57/57.

v3.16.0 2026-05-10

Geladene PDF-Dokumente durchlaufen nun einen inhaltsgesteuerten Versionserkennungsdurchgang: Jedes indirekte Objekt wird durch die Feature-zu-Minimum-Version-Tabelle gegangen, die vom Speicherzeit-Gate verwendet wird, und FVersion wird über den literalen %PDF-X.Y-Header-Wert hinaus angehoben, wenn der Inhalt tatsächlich eine höhere Version erfordert. Zum Beispiel hebt ein /UserUnit-Seiteneintrag die effektive Version auf PDF 1.6 an, auch wenn der Datei-Header PDF 1.4 sagt.
Neue GetInformation-Schlüssel: 100 gibt HeaderVersion (literal %PDF-X.Y) zurück, 101 gibt DetectedFeatures (durch CRLF getrennte beim Laden gefundene Funktionen) zurück, 102 gibt AutoBumpedFeatures (durch CRLF getrennte Funktionen, die writerseitig EnsureMinVersion ausgelöst haben) zurück.
Das Speicherzeit-Gate ist nicht betroffen: Dokumente, deren effektive Version beim Laden angehoben wurde und dann explizit mit SetInformation(0, ...) heruntergestuft wurde, erzeugen beim Speichern immer noch LastErrorCode 602.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 173/173, und C++Builder Win64x GoogleTest bestand 57/57.

v3.15.0 2026-05-10

Writer-Einstiegspunkte, die Funktionen produzieren, die eine bestimmte minimale PDF-Version erfordern, heben die PDF-Version des Dokuments nun automatisch an. SetTransparency auf einem als PDF 1.3 markierten Dokument aufzurufen, hebt den Header nun auf PDF 1.4 statt das Speichern mit LastErrorCode 602 zu scheitern.
Der gleiche Auto-Bump wurde in SetPageUserUnit (>=1.6), Encrypt mit Strength 1/2/3/4 (jeweils >=1.4/1.6/1.7/1.7) und die Zwei-Seiten-Varianten von SetPageLayout (>=1.5) eingebaut.
Verhaltenänderung gegenüber 3.14.x: Anwendungen, die zuvor auf das v3.12.6 "Speicherziel lehnt writer-emittierte Funktionen ab"-Gate setzten, gelingen nun bei der angehobenen Version. Geladene PDFs, die bereits Funktionen höherer Versionen enthalten, durchlaufen immer noch das bestehende Speicherzeit-Gate, sodass das Laden eines markierten PDF und das Auswählen von PDF 1.3 immer noch mit LastErrorCode 602 scheitert.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 170/170, und C++Builder Win64x GoogleTest bestand 57/57.

v3.14.3 2026-05-10

Die Speicherzeit-PDF-Versionskonformität erkennt nun auch die verbleibenden PDF 1.6 3D-Wörterbuchtypen (/Type /3DStream /3DRef /3DBackground /3DRenderMode /3DLightingScheme /3DCrossSection /3DNode) und die PDF 1.7 Redact-, RichMedia- und Projection-Annotations-Subtypen plus die /Type /Requirement- und /ReqHandler-Begleit-Wörterbücher.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 168/168, und C++Builder Win64x GoogleTest bestand 57/57.

v3.14.2 2026-05-10

Die Speicherzeit-PDF-Versionskonformität erkennt nun auch PDF 1.5-Funktionen: /XFA-Formulare, /AlternatePresentations, /Renditions-Namensbaum, die Multimedia-Wörterbücher /Type /Rendition /MediaCriteria /MediaPermissions /MediaPlayers und den Screen-Annotations-Subtyp.
Das Speichern als PDF 1.4 lehnt nun Dokumente ab, die diese Funktionen tragen, mit LastErrorCode 602.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 166/166, und C++Builder Win64x GoogleTest bestand 57/57.

v3.14.1 2026-05-10

Die Speicherzeit-PDF-Versionskonformität erkennt nun auch PDF 1.4-Funktionen: markierte PDF /StructTreeRoot /MarkInfo und StructElem-Wörterbücher, die Dokument /Lang- und Seiten /Tabs-Einträge, /OutputIntents und /OutputIntent-Wörterbücher, die /UR3-Nutzungsrechte-Signatur und die PDF 1.4-Annotations-Subtypen Polygon, PolyLine, Caret, Ink, Popup und Watermark.
Das Speichern als PDF 1.3 lehnt nun Dokumente ab, die diese Funktionen tragen, mit LastErrorCode 602.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 165/165, und C++Builder Win64x GoogleTest bestand 57/57.

v3.14.0 2026-05-10

Die Speicherzeit-PDF-Versionskonformität erkennt nun auch PDF 1.3-Funktionen wie weiche Schattierungen, Funktionsobjekte, ICCBased- und DeviceN-Farbräume, /TrimBox /BleedBox /ArtBox-Seiteneinträge, /ToUnicode-CMaps, Datei-Anhang- und /Sound- und /Movie-Annotationen, /Type /Filespec- und /Type /EmbeddedFile-Wörterbücher, die /Group /EF /Alternates /Mask-Schlüssel und JavaScript-Aktionen.
PDF 1.2-Aufrufer speichern nun unter dem PDF 1.3-Vertrag: Der literale %PDF-1.2-Header bleibt erhalten, aber das Gate akzeptiert PDF 1.3-Funktionen. PDF 1.4- und spätere Funktionen werden weiterhin mit LastErrorCode 602 abgelehnt.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 162/162, und C++Builder Win64x GoogleTest bestand 57/57.

v3.13.0 2026-05-10

Das PDF-Versionskonformitäts-Gate, das spätversionierte Funktionen beim Speichern ablehnt, wurde in ein dediziertes Modul umgestaltet, sodass der Regelsatz wachsen kann, ohne den Dokumentkern zu beeinflussen.
Keine für Benutzer sichtbare Verhaltenänderung gegenüber v3.12.7: dieselben Out-of-Version-Funktionen werden weiterhin mit LastErrorCode 602 abgelehnt.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 155/155, und C++Builder Win64x GoogleTest bestand 57/57.

v3.12.7 2026-05-09

Erweiterte automatisierte Testabdeckung für den PdfToImage-Direktzugriffs-Rendering-Workflow in den Delphi DUnitX- und C++Builder GoogleTest-Suites.
Der Delphi VCL GUI-Test-Runner registriert nun die Syntax- und XRef-Fixtures, passend zur Abdeckung des Konsolen-Runners.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 147/147, und C++Builder Win64x GoogleTest bestand 57/57.

v3.12.6 2026-05-09

Das Speichern als PDF 1.3, 1.4, 1.5, 1.6 oder 1.7 erzwingt nun die ausgewählte Version als vollständigen Speicher-Ausgabe-Vertrag.
Vollständige Speichern entfernen Katalog-/Version-Überschreibungen, entfernen nicht unterstützte Katalog-Erweiterungs- und Metadaten-Einträge für niedrigere Ziele und unterdrücken PDF 1.4 XMP-Metadatenstreams beim Speichern als PDF 1.3.
SaveToFile, SaveToString und SaveToStream scheitern nun mit LastErrorCode 602, wenn die ausgewählte PDF-Zielversion niedriger ist als Funktionen, die noch im Dokument vorhanden sind, wie Transparenz, optionaler Inhalt, JPX, UserUnit, 3D oder AES-Crypt-Filter-Funktionen.

v3.12.5 2026-05-09

Verbesserte PDF 1.7-Literalzeichenketten-Analyse, sodass unbekannte Escape-Sequenzen den Backslash gemäß Standardanforderung ignorieren.
Oktale Escapes für Literalzeichenketten verbrauchen nun nur oktale Ziffern und behalten eine folgende nicht-oktale Ziffer als reguläre Zeichenkettendaten bei.
Regressionsabdeckung für unbekannte Literalzeichenketten-Escapes und gemischte oktal/nicht-oktale Escape-Sequenzen hinzugefügt.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 141/141.

v3.12.4 2026-05-09

Verbesserte PDF 1.7-Lexikalanalyse, sodass Namensobjekte nun korrekt am rechten Klammertrennzeichen anhalten.
SmartAccess-Laden von xref-Stream komprimierter Objekteinträge, deren Objektstromnummer größer als die PDF-Bytelänge ist, behoben.
Regressionsabdeckung für rechte Klammer-Namens-Trennzeichen und spärliche komprimierte Objekt-xref-Stream-Einträge hinzugefügt.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 139/139.

v3.12.3 2026-05-08

Verbesserte PDF 1.7-Kompatibilität für verschlüsselte Dokumente für Standard-Sicherheits-Handler-Dateien, die StrF, StmF, EFF, Identity, None oder benannte StdCF-Style-Crypt-Filter verwenden.
Metadatenstreams respektieren nun EncryptMetadata=false während Entschlüsselungs-, Verschlüsselungs- und Kopier/Speicher-Workflows, statt wie gewöhnliche Streams verarbeitet zu werden.
Eingebettete Dateistreams tragen nun /Type /EmbeddedFile und verwenden den Entscheidungspfad des Crypt-Filters für eingebettete Dateien, wenn verschlüsselte Dokumente geladen oder gespeichert werden.
Externe eingebettete Dateistreams befördern nun FDecodeParms zu DecodeParms, wenn FFilter zu Filter befördert wird, und behalten Stream-Decode-Parameter bei.
Neue AES-verschlüsselte PDFs schreiben nun Crypt-Filter Length-Werte als Bitlängen, passend zum PDF 1.7-Crypt-Filter-Wörterbuch-Vertrag.
XRef-Stream Prev/XRefStm-Werte und große numerische Offsets behalten nun 64-Bit-Präzision durch Parser- und SmartAccess-Pfade.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 137/137.

v3.12.2 2026-05-08

Verbesserte PDF 1.7-Stream-Decodier-Kompatibilität. Die generische Stream-Decodierung respektiert nun /DP als DecodeParms-Alias, löst indirekte Decode-Parameter-Array-Einträge auf und akzeptiert die Standard-Filter-Abkürzungen /AHx und /LZW.
Großdatei-PDF-Ausgabe schreibt nun xref-, startxref-, Linearisierungs- und Digital-Signatur-ByteRange-Offsets durch 64-Bit-Formatierungspfade, statt diese Werte durch 32-Bit-Integer-Helfer einzuengen.
Geladene Dokumente behandeln einen Katalog-/Version-Eintrag nun als effektive PDF-Version, wenn er neuer als die Datei-Header-Version ist.
Umgeschriebene xref-Stream-Trailer behalten keine Nur-Stream-DecodeParms-Schlüssel mehr bei, wenn PDFlibPas sie als klassische Trailer-Wörterbücher speichert.
Validierung: Delphi Win32 und Win64 DUnitX-Suites bestanden jeweils 134/134.

v3.12.1 2026-05-06

Generierte PDFs öffnen sich nun mit der ersten Seite, die an die verfügbare Höhe des Viewer-Fensters angepasst ist, sodass die gesamte erste Seite von oben nach unten bei der größten Zoomstufe sichtbar ist, die in das Fenster passt. Konfigurieren Sie eine benutzerdefinierte OpenAction (SetOpenActionDestination, SetOpenActionMenu, SetOpenActionJavaScript) im Dokument, um diese Voreinstellung zu überschreiben.

v3.12.0 2026-05-06

Die Windows-Statik-Backends enthalten nun libjpeg-turbo NASM SIMD-Objekte für Win32 und Win64 sowie zlib-ng x86 SIMD-Dispatch-Objekte für das Win64x zlib-ng-Set.
Überarbeitete zlib-ng-Rebuild-Skripte, sodass Win64x bcc64x und diagnostische MSVC-Builds die generischen, SSE2-, SSSE3-, SSE4.1/SSE4.2-, PCLMULQDQ- und AVX2-Quelldateien mit pro Datei eingestellten Feature-Flags kompilieren, statt sich auf einen globalen Compiler-Schalter zu verlassen.
32-Byte-ausgerichtete malloc/calloc/realloc/free-CRT-Stubs für die statischen C-Bibliotheken hinzugefügt und TPDFJPEGImage.Compress repariert, sodass jpeg_mem_dest-Puffer durch denselben C free-Pfad freigegeben werden, der sie zugewiesen hat.
Erweiterte die öffentlichen Validierungshinweise, um die strenge automatisierte Abdeckung hinter diesem Release hervorzuheben: Bibliotheks-Builds, Komprimierungs-Round-Trips, HelloWorld /FlateDecode-Ausgabe, JPEG-Rendering, Bild-Workflows, Schriften, Formulare, Sicherheit, Signierung, Drucken und C++Builder demo-abgeleitete Workflows.

v3.11.0 2026-05-05

Windows Flate-Komprimierung und -Dekomprimierung auf zlib-ng im zlib-kompatiblen Modus umgestellt. Win32, Delphi Win64 und C++Builder Win64x verknüpfen nun ABI-passende zlib-ng-Statik-Objekt-Sets aus Lib\thirdparty\Win32, Lib\thirdparty\Win64 und Lib\thirdparty\Win64x.
Der Win64-Pfad geht nicht mehr durch Delphis System.ZLib-Einheit, sodass PDF-Stream-Komprimierung/-Dekomprimierung wie der 32-Bit-Build vom zlib-ng-Backend profitieren kann.
Ein kleines zlib-ng-Brückenobjekt für Win64-Builds hinzugefügt, sodass der Pascal-Code stabile zlib-kompatible Einstiegspunkte behält, während Delphi und C++Builder ihre eigenen Linker-kompatiblen Objekt-Sets verbrauchen.
Alle C++Builder-Demo-Projekte aktualisiert, um PDFLIB_CPPBUILDER zu definieren, passend zum GoogleTest-Runner und verhindert, dass Win64x-Demos die Delphi Win64 zlib-ng-Objekte verknüpfen.

v3.10.3 2026-05-01

Die C++Builder GoogleTest-Suite erweitert, um jede Demo unter Demo\C++Builder abzudecken. Das 7-Fixture phase-1-Layout wuchs auf 15 Fixtures / 52 GoogleTest-Fälle, alle auf Win64x bestanden. Neu abgedeckte Demos: AddFormattedTitle, AddTextImage, AddTrueTypeSubsettedFont, AddWebLink, CanvasText, CaptureToNewSize, CopyPageRanges, CreateWithImage, CreateWithImageToStream, DoInTheStream, DrawWrappedText, EditFormField, EmbeddedFonts, ExtractAnnotAttach, ExtractEmbeddedFonts, ExtractImage, ImageToPdf, ImportEMF, MultiFunction (Renderer-Wechsel), PageOperations, PdfDecrypt, PdfPermission, PrintPDF, TextMeasure, TextPaging.

v3.10.2 2026-05-01

C++Builder GoogleTest-Runner unter Tests\C++Builder hinzugefügt, der Lib\PDFlibrary.pas durch dieselben {$JPHNE}-emittierten HPP-Header laufen lässt, die die C++Builder-Demos verwenden. Die erste Phase spiegelt sieben Kern-Delphi-Szenarios (HelloWorld, DrawShapes, CreateTable, PdfEncrypt, ExtractText, PdfSigning, PdfToImage-Rendering) als 17 GoogleTest-Fälle, alle auf Win64x bestanden.
Die Delphi DUnitX-Suite mit Tests.Print erweitert, das die PrintPDF- und ShowPrinterBins-Demos abdeckt (Standarddrucker-Aufzählung, Benutzerdrucker-Einrichtung, Druckoptionen, Druckauftrag zur Datei umleiten), und einen Renderer-Wechsel-Test in Tests.Render, der die GDI+- / PDFium- / Cairo-Engine-Auswahl der MultiFunction-Demo auf derselben Quell-PDF ausführt.

v3.10.1 2026-05-01

57 benannte Seitengrößen zu SetPageSize hinzugefügt, sodass dieselben kanonischen Seitengrößennamen auch hier funktionieren: SIZE8X11, QUADA0, DOUBA0, B0PLUS, ENVB4/B5/C6/DL/MONARCH, ENV9/10/11, ANSIA/B/C/D/E, ARCHA/B/C/D/E1/E, SHIROKU, G1K, USBC/EUBC/ASBC, ID1/ID2/ID3, ONEINCH/TWOINCH/L2INCH/USVISA, P2R..P24R / S8R / P4D photo prints, plus the Chinese / Taiwanese octavo and sextodecimo sheet formats LARGE/STANDARD/CROWN/ROC 8K and the matching 16K halves.

v3.10.0 2026-04-30

Native C++Builder-Versionen für jedes Delphi-Beispiel unter Demo hinzugefügt. Die Demos für PDF-Erstellung, Seitenmanipulation, Schriften, Bilder, Sicherheit, Signierung, Rendering und Drucken können nun aus C++Builder gebaut und ausgeführt werden, ohne irgendeinen Delphi-seitigen Wrapper.
Jede neue Demo liegt in Demo\C++Builder\<Name>\ als Konsolenprojekt, das Lib\PDFlibrary.pas direkt verbraucht und die zur Ausführung benötigten Eingabedateien mitliefert.
Eine kurze englische Readme.txt zu jedem Delphi-Demo-Ordner hinzugefügt, die beschreibt, was die Demo zeigt, auf welche API sie sich konzentriert und wie sie auszuführen ist; eine HTML-Übersicht unter Demo\Delphi\index.html verlinkt zu allen Demos, nach Themen gruppiert.
Die gleiche Readme.txt für jede C++Builder-Demo gespiegelt, mit einem Run-Abschnitt, der für den Konsolen-Workflow umgeschrieben wurde (argv-Argumente statt Open/SaveDialogs); ein passendes Demo\C++Builder\index.html listet jede C++Builder-Demo mit denselben Themengruppen auf.
Einen Speicherleck in der ImportEMF-Demo behoben (die TPDFlib-Instanz wurde erstellt, aber nie freigegeben).

v3.9.14 2026-04-30

Die Seitenbereich-Kopier-Demo behoben, sodass sie tatsächlich Seiten kopiert, statt immer einen Fehler zu melden.
Die umgebrochenen Text- und HTML-Pagination-Demos aufgeräumt, sodass sich jede Demo auf ihre eigene API konzentriert und von einem einzigen Button aus läuft.
Zwei Demo-Projekte (EmbeddedFonts und PdfPermission) umbenannt, sodass die kompilierten ausführbaren Dateien zu den Ordnernamen passen statt zu älteren Prototyp-Namen.

v3.9.13 2026-04-30

Einen Stream-Positions-Fehler im internen Puffer-Reader behoben: Zwei-Byte-Wort-Lesungen verschoben den Lesecursor um vier Bytes statt um zwei. In Puffern, die länger als zwei Bytes sind, landeten nachfolgende Lesungen am falschen Offset und gaben stillschweigend falsche Daten zurück. Der Effekt war am sichtbarsten beim Analysieren binärer Datenstrukturen, die Byte- und Wort-Lesungen verschachteln.
Eine automatisierte DUnitX-Test-Suite eingeführt (Konsolen- und VCL GUI-Runner), die Utility-Einheiten — Puffer, AES, ZLib, Unicode und Digest-Hashing — und Bibliotheksebene-Workflows einschließlich Dokumenterstellung, Speichern in Datei und Speichern in Stream, Lade-Round-Trips und AES-128/AES-256-Verschlüsselung abdeckt.

v3.9.12 2026-04-30

Das GDI+-Bildrendering verwendet nun standardmäßig glatte, hochwertige bikubische Interpolation, wenn Rasterbilder auf Bildschirm- oder Export-Auflösung skaliert werden. Zuvor war die Voreinstellung der Nearest-Neighbour-Modus, der bei kleinen Bildern (Logos, Vorschaubilder), die für Bildschirmvorschau oder High-DPI-Export vergrößert wurden, sichtbare Treppenstufenartefakte erzeugte. Aufrufer, die den schärferen Nearest-Neighbour-Modus bevorzugen, können das alte Verhalten über SetGDIPlusOptions wiederherstellen.

v3.9.11 2026-04-30

Cairo-Rendering von PDF-Bildern, die Farbschlüssel-Transparenz (ein /Mask-Farbbereichs-Array im Bildwörterbuch) verwenden, behoben. Zuvor ließ der Cairo-Renderer, wenn eine Seite ein Bild mit dieser Form von Transparenz enthielt, das Bild vollständig weg, anstatt es mit dem Seitenhintergrund zu komponieren. Die Korrektur leitet einen pixelweisen Alphakanal aus den deklarierten Farbschlüssel-Bereichen ab und rendert das Ergebnis als transparentes Bild, was visuell mit dem GDI+-Renderer konsistente Ausgabe erzeugt.

v3.9.10 2026-04-30

Eine Cairo-Rendering-Regression behoben, bei der alle Seiteninhalte, die einer geclippten Bildsequenz folgten, fälschlicherweise auf das Clipping-Rechteck des Bildes beschränkt waren. PDF-Seiten, die den Grafikstatus speichern, einen Clipping-Pfad anwenden, ein Bild malen und dann den Status wiederherstellen — eine gängige Layout-Technik für gerahmte oder umrandete Bilder — würden allen nachfolgenden Text, Formen und Grafiken nur innerhalb des geclippten Bereichs rendern. Cairo-Statussichern und -Wiederherstellen werden nun korrekt auf die PDF q/Q-Operatoren abgebildet, sodass die Clipping-Region nach dem Zeichnen des Bildes verworfen wird.

v3.9.9 2026-04-29

Eine Cairo-basierte PDF-Rendering-Engine als dritte Rendering-Option neben GDI+ und PDFium hinzugefügt. Rufen Sie SelectRenderer(2) vor dem Rendering auf, um sie zu aktivieren; die Engine erfordert cairo.dll aus dem mitgelieferten DLL\Cairo-Ordner. Das Cairo-Rendering unterstützt dieselben Ausgabemodi wie GDI+: Bitmap-Datei und Stream-Export (BMP, JPEG, PNG, GIF, TIFF, G4 TIFF), Gerätekontext-Rendering und direkte Druckerausgabe.
Die MultiFunction View/Print-Demo bietet nun einen Drei-Wege-Renderer-Selektor, sodass Benutzer GDI+, PDFium und Cairo-Ausgabe ohne Codeänderungen Seite an Seite auf demselben Dokument vergleichen können.

v3.9.8 2026-04-29

Zwei spürliche Compiler-Diagnosen im Win32 C-Runtime-Shim unterdrückt, die in RAD Studio 13.1 und später erschienen. Eine Veraltungswarnung (W1000) wurde ausgelöst, weil ein Compiler-Versions-Schutz nicht an Compiler propagiert wurde, die neuer als Delphi 2009 sind, was sie dazu brachte, gegen eine veraltete Speicherverwalter-API zu kompilieren. Ein unbenutzter Variablen-Hinweis (H2164) wurde für eine interne Kompatibilitätsvariable ausgelöst, die nur für Delphi 7-Builds benötigt wird; sie ist nun auf den Bedingungsblock dieser Version beschränkt. Beide Probleme waren nur diagnostisch ohne Laufzeitwirkung.

v3.9.7 2026-04-29

Optionales PDFium-basiertes Seitenrendering auf Windows hinzugefügt, einschließlich BMP-Stream-Rendering, Gerätekontext-Rendering, Speicher-Rendering und Druckerausgabe.
Die Delphi MultiFunction View/Print-Demo mit einem Renderer-Selektor aktualisiert, sodass Benutzer zwischen dem bestehenden GDI+-Renderer und PDFium wechseln können.

v3.9.6 2026-04-29

Separate Inno Setup-Skripte für das vollständige PDFlibPas-Paket und das Trial-Paket hinzugefügt, mit release-fokussierten Ausschlüssen für Versionskontroll-Metadaten, Build-Ausgaben, IDE-Caches, lokale Agent-Dateien und mitgelieferte Drittanbieter-Quellbäume, die nicht Teil des ausgelieferten Pakets sind.
Der Trial-Installer baut und paketiert nun Trial-Binärbibliotheken für RAD Studio 11.3, 12.3 und 13.1 sowie die Trial Delphi-Demos, bevor die Setup-Ausführungsdatei generiert wird.

v3.9.5 2026-04-29

Win32-Bibliotheks-Builds unter RAD Studio 9.0 / Delphi XE2 behoben. Das Build-Skript übergab ein DCU-Ausgabeverzeichnis-Flag, das nur ab Delphi 2010 existiert; der Compiler von XE2 interpretierte das Flag anders, was zu einem verstellten Ausgabepfad und einem fatalen Fehler führte, bevor irgendeine Quelldatei verarbeitet wurde. Das Skript wählt nun automatisch das passende Flag basierend auf der Ziel-Compiler-Version aus.
Einen verwandten Compiler-Versions-Schutz im Bibliothekscode korrigiert, der eine namensqualifizierte, in XE4 eingeführte Runtime-Funktion unter einer XE2+-Bedingung aufrief. Builds, die XE2 und XE3 als Ziel haben, lösen nun stattdessen den korrekten Kompatibilitätsimport auf.

v3.9.4 2026-04-29

Drucker-Einrichtung für Netzwerk- und Server-freigegebene Drucker behoben, indem Papierschacht-, Medien-, Duplex-, Qualitäts- und andere Druckeinstellungen über das Drucker-DEVMODE-Handle statt über das Drucker-Gerätekontext-Handle angewendet werden.

v3.9.3 2026-04-29

Das mitgelieferte AES-Backend auf Brian Gladmans 2018 AES-Quellen sowohl auf Win32 als auch auf Win64 aufgefrischt. Reproduzierbare Build-Skripte erlauben nun, die statischen AES-Objekte jederzeit aus der Quelle neu zu bauen. Ein ABI-Defekt in den Pascal-Bindungen wurde im Prozess entdeckt und behoben: Den AES-CBC-Verschlüsselungs- und Entschlüsselungsfunktionen fehlte ihre C-Aufrufkonventions-Deklaration, sodass Win32-Builds Argumente stillschweigend in der falschen Registerreihenfolge übergaben und potenziell falsche verschlüsselte Ausgabe erzeugten. Win64-Builds waren nicht betroffen, weil die Plattform eine einheitliche Aufrufkonvention erzwingt.
Die Drittanbieter-Rebuild-Skripte gehärtet, sodass die MSVC-basierten zlib-, JPEG- und CRT-Stub-Skripte sowohl vom Repository-Stamm als auch vom thirdparty-Verzeichnis aus gestartet werden können; zuvor mussten sie das Arbeitsverzeichnis auf den thirdparty-Ordner gesetzt haben.

v3.9.2 2026-04-29

Das JPEG 2000-Backend auf Win32 und Win64 vom alten OpenJPEG 1.5 auf OpenJPEG 2.5.4 aktualisiert. Beide Plattformen verwenden nun statisches Objekt-Linken, sodass JPEG 2000-Codierung und -Decodierung ohne eine zusätzliche Runtime-DLL funktionieren. Der moderne Codec bringt aktuelle JP2/J2K-Header-Behandlung, eine callback-gesteuerte Stream-API und akkumulierte Fehler- und Sicherheitskorrekturen vom Upstream-Projekt. Die öffentliche TJpeg2000Bitmap-API ist unverändert.

v3.9.1 2026-04-29

JPEG-Seitenrendering und Bildexport nach dem libjpeg-turbo-Upgrade behoben, wodurch die PdfToImage JPG-Konvertierung und die TPDFJPEGImage.SaveToStream-Ausgabe auf Win32 und Win64 wiederhergestellt werden.
Win32 libjpeg-turbo ABI-Bindungen korrigiert, sodass Callbacks, Strukturausrichtung, boolesche Felder und speicherbasierte JPEG-Ziele mit libjpeg-turbo 3.1.90 übereinstimmen.
Win32 FlateDecode-Stream-Dekomprimierung mit dem mitgelieferten zlib 1.3.2-Backend behoben, wodurch das Laden von PDF xref-Streams für Dateien wie das PdfToImage-Beispieldokument wiederhergestellt wird.

v3.9.0 2026-04-29

Das mitgelieferte JPEG 2000-Backend vom alten OpenJPEG 1.5 auf OpenJPEG 2.5.4 aktualisiert. JPEG 2000-Laden und -Speichern verwenden nun den modernen Codec, die callback-gesteuerte Stream-API und aktuelle JP2/J2K-Header-Behandlung, während die öffentliche TJpeg2000Bitmap-API erhalten bleibt.
Die JPEG 2000-Ausgabe wählt nun automatisch eine gültige OpenJPEG-Auflösungsanzahl für kleine Bilder, und das Win32-Statik-Backend hängt nicht mehr von fehlenden MSVCRT-Helper-Exporten ab.

v3.8.1 2026-04-29

Alle 16 kosmetischen Linker W1028 "Bad global symbol definition"-Warnungen auf Win32 und Win64 beseitigt. Quellebene-Umbenennungen entfernen die redundanten Pascal-seitigen Duplikate (jpeg_std_error und die jmemnobs-Allokator-Stubs werden nun ausschließlich aus der obj-Schicht aufgelöst); die drei verbleibenden bcc32 / vc64 obj-Symbole (jpeg_natural_order, jpeg_aritab, jpeg_nbits_table), die gegen Pascal-seitige Daten link-aufgelöst bleiben müssen, werden nun in einem ObjConv-Nachverarbeitungsdurchgang während thirdparty\build-jpeg-vc64.bat von ihren COFF-Symbolnamen befreit. Keine Änderung an der öffentlichen API; saubere Linker-Ausgabe für Delphi Win32- und Win64-Builds.

v3.8.0 2026-04-29

Win64 JPEG-Codec von IJG-Style libjpeg auf libjpeg-turbo 3.1.90 aktualisiert, was die JPEG-Migration abschließt, die in v3.7.0 (Win32) begann. Sowohl Win32- als auch Win64-Pfade teilen sich nun denselben modernen JPEG-Codec, mit denselben SIMD-optimierten inneren Schleifen und 30+ akkumulierten CVE- / Fuzz-Fixes vom Upstream. Die öffentliche PDFlibPas-API ist unverändert.

v3.7.0 2026-04-28

Win32 JPEG-Codec von IJG libjpeg-6b auf libjpeg-turbo 3.1.90 aktualisiert. Deutlich schnellere JPEG-Codierung/-Decodierung durch SIMD-optimierte innere Schleifen, plus die 30+ CVE- / Fuzz-Fixes, die in libjpeg-turbo upstream akkumuliert wurden. Die öffentliche PDFlibPas-API (TPDFJPEGImage-Klasse, DumpJPEG-Funktionen) ist unverändert; existierende PDF/JPEG-Codepfade laufen schneller ohne erforderliche Quelländerungen.

v3.6.0 2026-04-28

Win32 zlib von 1.2.x auf 1.3.2 aktualisiert. Beinhaltet die standardmäßigen 25+ CVE- / Fuzz-Fixes, die seit 1.2.8 upstream akkumuliert wurden, sowie die neuen inflateBack9- / inflateTree9-Einstiegspunkte, die von 64-Bit-Fenster-Streams verwendet werden. Die öffentliche PDFlibPas-API (DeflateStr / InflateStr / InflateStrParms) ist unverändert.
Der Win64 zlib-Pfad ist in dieser Version unverändert — er verwendet weiterhin die Delphi-mitgelieferte System.ZLib-Einheit.
Den Win64 Link-Zeit-CRT-Shim PDFlibCLibs.pas (in v3.5.0 eingeführt) für den Win32 zlib-Pfad aktiviert und memcpy- / memset- / malloc- / free-Symbole bereitgestellt, auf die die neuen zlib 1.3.2-obj-Dateien verweisen.

v3.5.0 2026-04-28

Frische Build-Infrastruktur für die mitgelieferten C-Bild- / Komprimierungsbibliotheken vendoriert: zlib 1.3.2, libjpeg-turbo 3.1.90, libtiff 4.7.1. Build-Skripte für sowohl Embarcadero bcc32 (Win32) als auch MSVC cl.exe (Win64) liegen in Lib/thirdparty/ neben den Quellbäumen, sodass jeder mit RAD Studio + VS2022 die statischen obj-Dateien aus sauberer Quelle neu bauen kann.
Build-Infrastruktur für OpenJPEG 2.5.4 hinzugefügt. Der OpenJPEG-Quellbaum selbst wird vom Benutzer unabhängig geholt (git clone uclouvain/openjpeg in Lib/thirdparty/OpenJPEG/), sodass er aktualisiert werden kann, ohne die Build-Konfiguration von PDFlibPas anzufassen.
Lib/PDFlibCLibs.pas wurde hinzugefügt, ein Win64-Linkzeit-CRT-Shim, der vom Win64-Backend verwendet wird. Er überbrückt die Lücke zwischen den mit MSVC kompilierten C-obj-Dateien und Delphis Win64-Linkern (dcc64 / Win64x ld.lld / BCB ilink64), die msvcrt.dll nicht automatisch einbinden.

v3.4.0 2026-04-28

Verschlüsselungsschlüssel-, AES-Initialisierungsvektor- und Perms-Berechtigungsblock-Generierung gegen vorhersagbare Zufallszahlenquellen gehärtet. Verschlüsselte PDFs, die auf Systemen mit ähnlicher Wanduhrzeit produziert wurden, sind nicht mehr trivial korrelierbar; AES-256-Dokumente behalten nun ihre volle Schlüsselstärke.
Bildwörterbuch-Analyse gegen fehlerhafte oder feindliche PDFs gehärtet, die unverstandig große Width-, Height-, BitsPerComponent- oder DeviceN-Komponentenzählungen deklarieren. Werte außerhalb des Bereichs werden vor jeder Pixelpuffer-Arithmetik gekappt, um Abstürze beim Öffnen solcher Dateien zu verhindern.
Querverweis- und Seitenbaumtraversierung gegen Dokumente gehärtet, deren /Prev xref-Ketten oder /Parent-Seitenlinks einen Zyklus bilden oder übermäßig tief sind. Der Reader weist fehlerhafte Strukturen nun sauber zurück, statt zu rekursieren, bis ihm der Stack ausgeht.

v3.3.1 2026-04-27

Die komponentenweisen Windows-Build-Skripte rationalisiert. Die DLL/-, OCX/- und Dylib/-Ordner tragen keine separaten build12-* / build13-*-Varianten mehr: jede Plattform hat nun ein einziges build-Win32 / build-Win64-Skript, das auf das neueste RAD Studio fixiert ist und ein optionales "debug"-Argument akzeptiert.
Inline-Begründungs-Kommentare um die PDFlibRenderer.pas-Render-Korrekturen hinzugefügt, die bereits in der anfänglichen Git-Basis vorhanden waren. Die Kommentare dokumentieren, warum SetPen Strichbreiten durch die aktive Canvas-Transformation skaliert und warum Type 3 Font CharProc d0/d1-Operatoren ihre Operanden verbrauchen müssen. Keine Laufzeitverhaltenänderung.

v3.3.0 2026-04-26

Transformiertes Strich-Rendering in PDFlibRenderer.pas behoben. SetPen wendet nun die aktuelle Canvas-Transformations-Skala auf PDF-Linienbreiten an, bevor Picasso aufgerufen wird, was übergroße oder untergroße Striche auf Pfaden verhindert, deren Koordinaten bereits transformiert wurden. Dies behebt Type 3 Glyph-Umrisse, die als dicke, unregelmäßige Blöcke rendern könnten.
Type 3 Font CharProc d0/d1-Behandlung im Inhaltsstrom-Parser behoben. d0 verbraucht nun seine zwei Breite-Operanden, und d1 verbraucht seine sechs Breite/Bounding-Box-Operanden, bevor spätere Zeichenbefehle ausgeführt werden, was verhindert, dass veraltete Operanden Glyph- oder Pfad-Geometrie korrumpieren.