Sparkompatibilitet per PDF-version

Version 3.23.0 behandlar den valda PDF-sparversionen som ett strikt kontrakt för fullständiga sparningar; När ett program anropar SetInformation(0, "1.2"), "1.3", "1.4", "1.5", "1.6" eller "1.7" skriver SaveToFile, SaveToString och SaveToStream utdata som matchar det valda målet, eller misslyckas innan någon utdata skrivs

Fullständiga sparningar tar bort Catalog /Version-överskrivningar så att ett inläst dokument inte tyst kan höja den effektiva versionen över den valda headern. Lägre versionsmål tar också bort Catalog /Extensions-poster som inte stöds, och PDF 1.3-mål utelämnar Catalog /Metadata och XMP Metadata-strömmar men bevarar dokumentets informationsordbok

Sparningens preflight avvisar kända funktioner från senare versioner i stället för att skapa en blandversionsfil. De kontrollerade gränserna omfattar PDF 1.3-sidrutor, inbäddade filströmmar, JavaScript-åtgärder, ICCBased- och DeviceN-färgrymder samt ToUnicode CMaps; PDF 1.4-transparens, Tagged PDF-strukturer, output intents och annoteringsnycklar; PDF 1.5-objektströmmar, valfritt innehåll, XFA, page tabs, append-only-flaggor för signaturfält och avancerade formulärfältsflaggor; PDF 1.6 UserUnit, OpenType-typsnittsprogram, 3D-ordböcker, NChannel-färgrymder och viewportdata; samt PDF 1.7 RichMedia, Projection, Redaction, avancerade annoteringar och ETSI-signatursubfilter; Samma regeluppsättning täcker också annotation /CA-opacity, JBIG2Decode, Metadata-strömmar, document-level EmbeddedFiles name tree, JPXDecode, xref streams, Crypt filters, AESV2 crypt filters och PDF 1.7 Requirements

PDF 1.7-krav på Adobe extension-level kontrolleras separat från PDF 1.7-headern. AESV3, AES-256, RichMedia, Projection, geospatiala ordböcker och ETSI-signatursubfilter måste ha en tillräcklig Catalog /Extensions /ADBE /ExtensionLevel-deklaration innan det valda sparmålet accepteras. Writer-ingångar som skapar sådana extension-level funktioner lägger automatiskt till motsvarande extensionsdeklaration när det valda sparmålet kan höjas till PDF 1.7

Sedan v3.67.0 är loader-side detektering av innehållsfunktioner lazy. Ett inläst dokument skannas inte omedelbart; detekteringen körs första gången den effektiva versionen eller load-time-diagnostiken används via GetInformation(0/101/103), GetPDFUADiagnostics, SaveToFile, SaveToString, SaveToStream eller relaterade append-save-vägar. Läsflöden som aldrig frågar efter dessa diagnostikvärden och aldrig sparar kan hoppa över skanningen helt

Sedan v3.67.1 grundtolkar detekteringsskanningen streamobjekt. Den granskar objektordböcker och streamklassificering men hoppar över stora streamkroppar, så detektering av filter, subtyper, färgrymder och versionsstyrande nycklar förblir likvärdig medan stora bildströmmar inte längre dominerar skanningen. Normala objektläsningar och alla sparvägar läser fortfarande hela streamkroppen när utdata kräver det

Sedan v3.67.2 har explicita val av sparversion prioritet över lazy detektering. På ett inläst dokument kör SetInformation(0, ...) och LockSaveVersion den väntande detekteringssnapshoten innan den begärda versionen tillämpas, så en senare sparning eller diagnostikfråga kan inte höja det valda målet bakom anroparen. Nyskapade dokument armeras inte för loader-side detektering, vilket motsvarar det tidigare writer-only beteendet för versionskontroll

TPDFlib-anropare får LastErrorCode 602 när den valda målversionen är lägre än en funktion som fortfarande finns i dokumentet. Välj en nyare målversion eller ta bort den inkompatibla funktionen innan du sparar