PDF Version-Specific Save Compatibility

Version 3.23.0 treats the selected PDF save version as a strict full-save output contract. When an application calls SetInformation(0, "1.2"), "1.3", "1.4", "1.5", "1.6", or "1.7", SaveToFile, SaveToString, and SaveToStream write output that matches the selected target or fail before writing output

Full saves remove Catalog /Version overrides so a loaded document cannot silently raise the effective version above the selected header. Lower-version targets also remove unsupported Catalog /Extensions entries, and PDF 1.3 targets omit Catalog /Metadata and XMP Metadata streams while preserving the document information dictionary

The save preflight rejects known later-version features instead of producing a mixed-version file. The checked boundaries include PDF 1.3 page boxes, embedded file streams, JavaScript actions, ICCBased and DeviceN color spaces, and ToUnicode CMaps; PDF 1.4 transparency, tagged-PDF structures, output intents, and annotation keys; PDF 1.5 object streams, optional content, XFA, page tabs, signature-field append-only flags, and advanced form-field flags; PDF 1.6 UserUnit, OpenType font programs, 3D dictionaries, NChannel color spaces, and viewport data; and PDF 1.7 rich media, projection, redaction, advanced annotations, and ETSI signature subfilters; The same rule set also covers annotation /CA opacity, JBIG2Decode, Metadata streams, the document-level EmbeddedFiles name tree, JPXDecode, xref streams, Crypt filters, AESV2 crypt filters, and PDF 1.7 Requirements

PDF 1.7 Adobe extension-level requirements are checked separately from the PDF 1.7 header. AESV3, AES-256, RichMedia, Projection, geospatial dictionaries, and ETSI signature subfilters must have a sufficient Catalog /Extensions /ADBE /ExtensionLevel declaration before the selected save target is accepted. Writer entry points that emit those extension-level features add the matching extension declaration automatically when the selected save target can be raised to PDF 1.7

Since v3.67.0, loader-side content feature detection is lazy. A loaded document is not scanned immediately; detection runs the first time the effective version or load-time feature diagnostics are consumed through GetInformation(0/101/103), GetPDFUADiagnostics, SaveToFile, SaveToString, SaveToStream, or related append-save paths. Read-only workflows that never query those diagnostics and never save can skip the scan entirely

Since v3.67.1, the detection scan shallow-parses stream objects. It inspects object dictionaries and stream classification while skipping large stream bodies, so detection of filters, subtypes, color spaces, and version-gating keys remains equivalent while large image streams no longer dominate the scan. Normal object reads and every save path still read the full stream body when output requires it

Since v3.67.2, explicit save-version choices keep priority over lazy detection. On a loaded document, SetInformation(0, ...) and LockSaveVersion run the pending detection snapshot before applying the requested version, so a later save or diagnostic query cannot raise the selected target behind the caller. Newly-created documents are not armed for loader-side detection, matching the earlier writer-only version-control behavior

TPDFlib callers receive LastErrorCode 602 when the selected target version is lower than a feature still present in the document. Choose a newer target version or remove the incompatible feature before saving