Speicherkompatibilität nach PDF-Version

Version 3.23.0 behandelt die ausgewählte PDF-Speicherversion als strikten Vertrag für vollständige Speicherläufe. Wenn eine Anwendung SetInformation(0, "1.2"), "1.3", "1.4", "1.5", "1.6" oder "1.7" aufruft, schreiben SaveToFile, SaveToString und SaveToStream eine Ausgabe, die zum gewählten Ziel passt, oder brechen vor dem Schreiben ab

Vollständige Speicherläufe entfernen Catalog /Version-Overrides, damit ein geladenes Dokument die effektive Version nicht stillschweigend über den ausgewählten Header heben kann. Niedrigere Zielversionen entfernen außerdem nicht unterstützte Catalog /Extensions-Einträge, und PDF 1.3-Ziele lassen Catalog /Metadata und XMP Metadata-Streams weg, behalten aber das Dokumentinformationswörterbuch bei

Die Speicher-Vorprüfung weist bekannte Funktionen späterer Versionen zurück, statt eine Datei mit gemischten Versionsanforderungen zu erzeugen. Geprüft werden unter anderem PDF 1.3-Seitenrahmen, eingebettete Dateistreams, JavaScript-Aktionen, ICCBased- und DeviceN-Farbräume sowie ToUnicode CMaps; PDF 1.4-Transparenz, Tagged-PDF-Strukturen, Output Intents und Annotationsschlüssel; PDF 1.5-Objektstreams, optionale Inhalte, XFA, Page Tabs, Append-only-Flags von Signaturfeldern und erweiterte Formularfeld-Flags; PDF 1.6 UserUnit, OpenType-Schriftprogramme, 3D-Wörterbücher, NChannel-Farbräume und Viewport-Daten; sowie PDF 1.7 RichMedia, Projection, Redaction, erweiterte Annotationen und ETSI-Signatur-Subfilter; Derselbe Regelsatz deckt außerdem Annotation /CA-Deckkraft, JBIG2Decode, Metadata-Streams, den dokumentweiten EmbeddedFiles-Namensbaum, JPXDecode, xref streams, Crypt filters, AESV2 crypt filters und PDF 1.7 Requirements ab

PDF 1.7-Anforderungen an Adobe-Erweiterungsstufen werden getrennt vom PDF 1.7-Header geprüft; AESV3, AES-256, RichMedia, Projection, Geodaten-Wörterbücher und ETSI-Signatur-Subfilter benötigen eine ausreichende Catalog /Extensions /ADBE /ExtensionLevel-Deklaration, bevor das ausgewählte Speicherziel akzeptiert wird; Writer-Einstiegspunkte, die solche Erweiterungsstufen-Funktionen ausgeben, fügen die passende Erweiterungsdeklaration automatisch hinzu, wenn das ausgewählte Speicherziel auf PDF 1.7 angehoben werden kann

Seit v3.67.0 erfolgt die inhaltsbezogene Erkennung auf der Loader-Seite verzögert; ein geladenes Dokument wird nicht sofort gescannt; die Erkennung läuft erst, wenn die effektive Version oder die Load-Time-Diagnosen über GetInformation(0/101/103), GetPDFUADiagnostics, SaveToFile, SaveToString, SaveToStream oder verwandte Append-Save-Pfade benötigt werden; reine Lese-Workflows, die diese Diagnosen nie abfragen und nie speichern, können den Scan vollständig überspringen

Seit v3.67.1 analysiert der Erkennungsscan Streamobjekte nur oberflächlich; er prüft Objektwörterbücher und die Stream-Klassifizierung, überspringt aber große Streamkörper; die Erkennung von Filtern, Subtypes, Farbräumen und versionsrelevanten Schlüsseln bleibt dadurch gleichwertig, während große Bildstreams den Scan nicht mehr dominieren; normale Objektlesevorgänge und jeder Speicherpfad lesen den vollständigen Streamkörper weiterhin, wenn die Ausgabe ihn benötigt

Seit v3.67.2 behalten explizite Speicher-Versionsentscheidungen Vorrang vor der verzögerten Erkennung; bei einem geladenen Dokument führen SetInformation(0, ...) und LockSaveVersion den ausstehenden Erkennungssnapshot aus, bevor die angeforderte Version gesetzt wird; eine spätere Speicherung oder Diagnoseabfrage kann das gewählte Ziel daher nicht hinter dem Aufrufer anheben; neu erstellte Dokumente werden für die Loader-seitige Erkennung nicht aktiviert, was dem früheren writer-only Versionsverhalten entspricht

TPDFlib-Aufrufer erhalten LastErrorCode 602, wenn die ausgewählte Zielversion niedriger ist als eine Funktion, die noch im Dokument vorhanden ist. Wählen Sie eine neuere Zielversion oder entfernen Sie die inkompatible Funktion vor dem Speichern