Opslagcompatibiliteit per PDF-versie

Versie 3.23.0 behandelt de gekozen PDF-opslagversie als een strikt contract voor volledige opslagbewerkingen. Wanneer een toepassing SetInformation(0, "1.2"), "1.3", "1.4", "1.5", "1.6" of "1.7" aanroept, schrijven SaveToFile, SaveToString en SaveToStream uitvoer die bij het gekozen doel past, of falen ze voordat er uitvoer wordt geschreven

Volledige opslagbewerkingen verwijderen Catalog /Version-overrides, zodat een geladen document de effectieve versie niet stilzwijgend boven de gekozen header kan verhogen. Doelen met een lagere versie verwijderen ook niet-ondersteunde Catalog /Extensions-vermeldingen, en PDF 1.3-doelen laten Catalog /Metadata en XMP Metadata-streams weg terwijl het documentinformatiewoordenboek behouden blijft

De opslagpreflight weigert bekende functies uit latere versies in plaats van een bestand met gemengde versies te produceren. De gecontroleerde grenzen omvatten PDF 1.3-paginavakken, ingesloten bestandsstreams, JavaScript-acties, ICCBased- en DeviceN-kleurruimten en ToUnicode CMaps; PDF 1.4-transparantie, Tagged PDF-structuren, output intents en annotatiesleutels; PDF 1.5-objectstreams, optionele inhoud, XFA, page tabs, append-only-vlaggen voor handtekeningvelden en geavanceerde formulierveldvlaggen; PDF 1.6 UserUnit, OpenType-lettertypeprogramma's, 3D-woordenboeken, NChannel-kleurruimten en viewportgegevens; en PDF 1.7 RichMedia, Projection, Redaction, geavanceerde annotaties en ETSI-handtekeningsubfilters; Dezelfde regelset dekt ook annotation /CA-opacity, JBIG2Decode, Metadata-streams, de document-level EmbeddedFiles name tree, JPXDecode, xref streams, Crypt filters, AESV2 crypt filters en PDF 1.7 Requirements

PDF 1.7 Adobe-extension-level vereisten worden apart van de PDF 1.7-header gecontroleerd. AESV3, AES-256, RichMedia, Projection, geospatiale woordenboeken en ETSI-handtekeningsubfilters moeten een toereikende Catalog /Extensions /ADBE /ExtensionLevel-declaratie hebben voordat het gekozen opslagdoel wordt geaccepteerd. Writer-ingangen die zulke extension-level functies produceren, voegen de bijbehorende extensiedeclaratie automatisch toe wanneer het gekozen opslagdoel naar PDF 1.7 kan worden verhoogd

Sinds v3.67.0 is loader-side detectie van inhoudsfuncties lazy. Een geladen document wordt niet meteen gescand; detectie loopt pas wanneer de effectieve versie of de load-time diagnostiek wordt gebruikt via GetInformation(0/101/103), GetPDFUADiagnostics, SaveToFile, SaveToString, SaveToStream of verwante append-save-paden. Alleen-lezen workflows die deze diagnostiek nooit opvragen en nooit opslaan, kunnen de scan volledig overslaan

Sinds v3.67.1 parseert de detectiescan streamobjecten oppervlakkig. De scan inspecteert objectwoordenboeken en streamclassificatie terwijl grote streamlichamen worden overgeslagen, zodat detectie van filters, subtypes, kleurruimten en versie-afhankelijke sleutels equivalent blijft terwijl grote afbeeldingsstreams de scan niet meer domineren. Normale objectlezingen en elk opslagpad lezen nog steeds het volledige streamlichaam wanneer de uitvoer dat vereist

Sinds v3.67.2 houden expliciete keuzes voor de opslagversie voorrang boven lazy detectie. Op een geladen document voeren SetInformation(0, ...) en LockSaveVersion eerst de wachtende detectiesnapshot uit voordat de gevraagde versie wordt toegepast, zodat een latere opslag- of diagnostiekquery het gekozen doel niet achter de aanroeper om kan verhogen. Nieuw gemaakte documenten worden niet geactiveerd voor loader-side detectie, gelijk aan het eerdere writer-only versiecontrolegedrag

TPDFlib-aanroepers ontvangen LastErrorCode 602 wanneer de gekozen doelversie lager is dan een functie die nog in het document aanwezig is. Kies een nieuwere doelversie of verwijder de incompatibele functie voordat u opslaat