Native Linux C ABI annotation exchange

hpdf_document_execute_json_v1 exposes annotations.export and annotations.import through the existing versioned operation descriptor and callback IO interfaces

Load the PDF into the document context first; annotation import uses InputIO for the selected XFDF or FDF bytes, OutputIO for the saved PDF and ResultIO for JSON result metadata

{"schemaVersion":1,"type":"annotations.export","format":"xfdf"}

XFDF export writes UTF-8 XML to OutputIO and reports annotationCount, skippedAnnotationCount, decodedAttachmentBytes and outputBytes

{"schemaVersion":1,"type":"annotations.import","format":"xfdf",
 "annotationLimits":{"maxBytes":1048576,"maxAnnotations":1000,
 "maxNodes":100000,"maxDepth":32,"maxWorkingBytes":67108864}}

Import reports updated and annotationProfile, then adopts the saved revision only once both PDF and result callbacks succeed

Input/output callback failures, result callback failures and cancellation preserve the exact previously committed context; external callbacks can already have received a partial stream before a later callback failure

Capability JSON describes the selected exchange profiles; the XFDF profile retains mapped types, append import, embedded data, forward replies and popup objects

Annotation limits can lower the operation capacities and cannot increase them; MaxBytes is also capped by operation memory divided by 64, working storage by half of operation memory, and export bytes by the output limit

Import accepts the existing signaturePolicy object for CAdES, trust and timestamp verification settings, and enforces annotation permissions and authenticated DocMDP policy

Empty ABI imports retain the committed PDF bytes whilst returning zero updates

Local named and explicit destinations and GoTo actions preserve actual page references and bounded exact decimal coordinates through the shared annotation codec

The ELF SONAME and HOTPDF_1.0 symbol version remain unchanged, and existing C consumers continue to use the same public operation descriptor

Mapped profile and native API · Linux C ABI · Form-data operations

Standard stamp appearance transport preserves actual Form streams and bounded acyclic font, image and graphics resources through base64 typed XML

FDF object-graph operations

{"schemaVersion":1,"type":"annotations.import","format":"fdf"}

Select format="fdf" for binary annotation graphs through the same operation descriptor and InputIO, OutputIO and ResultIO callbacks; annotations.export writes FDF bytes to OutputIO

The FDF profile preserves supplied AP and RO resources, shared indirect objects and contextual local GoTo page references; a matching annotation NM on the same page identifies a replacement, whilst unnamed or unmatched annotations are appended

Successful FDF import reports annotationProfile="pdf-object-graph-v1" and an integer updated count; a zero-update operation preserves the exact last committed PDF bytes

FDF annotationLimits also accepts maxObjects; all limits remain constrained by the enclosing operation, with failure and cancellation retaining the existing callback transaction guarantees

Annotation-only operations reject nonempty Fields and embedded Differences; action data is transported without executing it

See FDF graph behaviour and boundaries and native FDF limits

Annotation removal

{"schemaVersion":1,"type":"annotations.remove","annotations":[{"page":0,"name":"review-note"}]}

annotations.remove uses the current document or an independent PDF supplied through InputIO, then publishes PDF OutputIO and JSON ResultIO before committing the context

The result reports removed and annotationProfile="page-and-nm-removal-v1"; annotationLimits bounds annotation count, operations, name bytes and working storage

Failure or cancellation preserves the committed context; callers stage callback sinks themselves because already-written bytes cannot be retracted