Annotation XFDF destinations

Native annotation XFDF, Windows file jobs and V1 callbacks, and native Linux V1 callbacks preserve named destinations and local explicit page targets in Link annotations, with a separate remote GoToR path

A direct Dest maps to the annotation's PDF destination object, while OnActivation/Action/GoTo/Dest maps to a local GoTo action; the page index is zero-based and is bound to the actual indirect page object during import

The attribute model follows Adobe's XML Forms Data Format Specification, Version 3.0, printed pages 59-68 and 88; PDF destination semantics are defined in ISO 32000

Canonical XYZ export omits coordinates whose PDF object is null; missing optional coordinates preserve the viewer's current coordinate or zoom, and zoom zero retains the standard PDF meaning

The compatibility profile also accepts literal null and empty coordinate attributes as null values; required FitH/FitV/FitBH/FitBV attributes are emitted as literal null when their PDF object is null, without a claim of ISO schema certification

FitR requires all four numeric bounds; required attributes cannot be omitted from other Fit modes, and Page must be a decimal integer identifying an existing page

Precision and bounds

Qualified Adobe element names and inherited namespace bindings preserve the same targets; foreign destination namespaces and duplicate XML attributes are rejected before annotation creation

Coordinates must be finite, have an exact absolute decimal value no greater than 1000000, and use nonnegative zoom; numeric input and expanded decimal output are limited to 8192 characters

Signed decimals and scientific notation are accepted within those limits, then written as PDF decimal tokens without exponent notation; source tokens retain authored precision even when the legacy public Single value rounds or underflows

Saved PDF reload and subsequent XFDF export preserve the retained decimal token, including long fractions close to the coordinate limit

Transactions and callbacks

The native file transaction validates targets before publication, preserves the loaded graph and previous target on failure, and uses the existing annotation, object, depth, byte and working-storage budgets

Windows and Linux JSON entry points use the same mapped codec through their existing V1 operation records; failed callbacks or cancellation retain the previously committed PDF, while caller-owned callback sinks may have received candidate bytes

A failed write callback is not retried through an aliased output or result sink; the same rule applies to two-handle comparison, and undefined write status values become the standard IO error status

The shared HPDFXFDF codec accepts a separate destination callback record in new overloads; the legacy access-record layout remains unchanged

The THotPDF loaded-annotation methods bind these callbacks automatically; direct codec callers must supply page count and page resolution for explicit targets

Boundaries

This profile maps local GoTo and destination data without executing actions; Launch, arbitrary action dictionaries, destination name-tree authoring, AP transport and annotation replacement/removal remain separate capabilities

Mapped annotation profile · Windows operations · Linux callbacks