SaveAsPdfR method

Deze API-entry behoudt identifiers, signatures, codeblokken en PDF-termen in hun oorspronkelijke vorm.

Saves the current document as a PDF/R-1 conformant file (ISO 23504-1:2020, the raster image transport and storage subset of PDF used for scanned documents).

SaveAsPdfR performs the regular SaveAs first, then layers an incremental update on top of the saved bytes that attaches PDF/R-1 file-format markers. PDF/R-1 (ISO 23504-1:2020) is the strict raster-image transport subset of PDF used by the TWAIN Working Group for scanned document workflows; it carries a fixed-size raster buffer per page, supports bitonal / grayscale / RGB images and FlateDecode / CCITTFaxDecode / DCTDecode compression only.

The post-processing injects five classes of bytes into the saved stream:

• The %PDF-raster-1.0 version-identification comment, written between the trailer dictionary and the startxref keyword (ISO 23504-1 §5). This is unique to PDF/R — the other PDF/x standards identify themselves through XMP and Info-dictionary entries instead.
• The document catalog stripped down to the §6.3 white list. Only the optional entries Version / ViewerPreferences / PageLayout / PageMode / AcroForm / Metadata are preserved; all other catalog entries (Names / Outlines / Dests / StructTreeRoot / OutputIntents / Lang / PageLabels / OCProperties / etc.) are removed.
• The Document Information Dictionary stripped to the §6.4.3 white list. Only Creator / Producer / CreationDate / ModDate are preserved; Title / Author / Subject / Keywords / Trapped are removed.
• A catalog /Metadata XMP stream carrying the four §6.4.4 Table 1 properties (xmp:CreatorTool, pdf:Producer, xmp:CreateDate, xmp:ModifyDate) plus xmp:MetadataDate.
• A trailer /ID array (recommended by the §5 example).

The output stays byte-identical to the base SaveAs result up to the end of the original PDF; only the incremental update is appended (and the source catalog / Info are replaced with stripped versions via same-object-number rewriting). The two overloads differ only in how the configuration is passed in: the file-name- only form uses TPdfRSaveOptions.Default with auto-population of the four Info fields and DocumentId from FPDF_GetMetaText / FPDF_GetFileIdentifier.

Returns True on success.

• SaveAsPdfR attaches the file-format-level markers PDF/R requires — it does not guarantee that the source PDF's content already satisfies PDF/R's structural restrictions. PDF/R is much stricter than the other PDF/x standards: each page must have exactly one /Contents entry, MediaBox must be [0 0 w h], only FlateDecode / CCITTFaxDecode (bitonal) / DCTDecode (8-bit gray or RGB) filters are allowed, no object streams, every indirect reference must have generation number zero, and each page is essentially a single raster image. PDFium-generated documents that already match this pattern (e.g. scanner output passed through PDFium for repackaging) work well; arbitrary content-rich PDFs typically do not.
• Use ValidatePdfR after SaveAsPdfR to confirm what the source actually achieves. Pair with a TWAIN Working Group PDF/R validator for full content-level verification.
• TPdfRSaveOptions.StripCatalogOptionalEntries and StripInfoOptionalEntries default to True; set them False if you want the injector to preserve all source entries (the output then won't meet §6.3 / §6.4.3 but the version marker and XMP are still attached).
• Encryption is permitted by PDF/R §6.2.3, but only with a %PDF-2.0 header and AES encryption. PDFium-generated PDFs use a 1.x header so encrypted output isn't a PDF/R-1 candidate without further re-saving.

SaveAsPdfRToStream, ValidatePdfR, PdfRConformance, SaveAsPdfA, SaveAsPdfX