function CommitIncrementalSave(Stream: TStream; out Info: TPdfIncrementalCommitInfo): Boolean;
| Stream | Destination for the complete document, including the baseline and every revision appended so far; nil raises EPdfError |
| Info | TPdfIncrementalCommitInfo receives object and byte counts, prior and new xref offsets, revision count, encryption and validation state, and file durability results |
| Result | True when the complete validated output was written |
function CommitIncrementalSave(const FileName: string; out Info: TPdfIncrementalCommitInfo): Boolean;
| FileName | Destination file, replaced atomically through a durable side file in the same directory |
| Info | The same TPdfIncrementalCommitInfo report as the stream overload, with Durable and ReplacedAtomically set after those file stages succeed |
| Result | True when the validated side file replaced the destination |
Diffs the live document against the state captured at the last commit, or against the baseline for the first one, and appends the changed objects plus a fresh cross-reference section. Earlier bytes are never rewritten, so every previous revision stays byte-identical and recoverable
AppendedByteCount is the size of the new revision alone, while PreviousOutputByteCount and OutputByteCount delimit the immutable prefix and complete result. PreviousXrefOffset and OutputXrefOffset identify the revision chain, and ChangedObjectCount reports how many objects the diff found
Every candidate passes sparse revision-boundary checks, a strict independent reopen, page-count and security-handler checks, and PDF MAC validation when present. Encrypted and Validated report these properties
The file overload writes beside the target, flushes the side file, closes and reopens it, repeats validation, then commits an atomic replacement. Windows requests write-through replacement; Unix verifies directory-flush support before replacement and flushes the parent directory after the rename
A failure before replacement leaves the prior target untouched and restores the session baseline and revision count. A Unix directory-flush failure after a successful rename raises EPdfOutputCommitError from the internal FPdfPlatform unit: the output has already been replaced, Info.ReplacedAtomically=True and Info.Durable=False, and the session retains the committed baseline so a later edit cannot append to obsolete output
Durable reports successful completion of the platform's requested flush stages. It does not certify storage hardware or a filesystem's behavior after power loss. Other file-save APIs using the same atomic replacement can also raise this committed-output exception after replacement; callers must distinguish that stage from failures that preserve the prior output
Calling without an open session raises EPdfError, so BeginIncrementalSave has to come first