Funktion HPDFXFDFImportAnnotations

function HPDFXFDFImportAnnotations(const Access: THPDFXFDFAccess;
  const Destinations: THPDFXFDFDestinationAccess;
  Root: THPDFXFDFNode): Integer; overload;

Mappt Annotation-XML durch die gelieferten Access-Callbacks und liefert die Anzahl der erzeugten Annotationen

Die separaten Destination-Callbacks binden lokale Seiten-Arrays an tatsächliche indirekte Dokumentseiten und bewahren benannte Unicode-Ziele und exakte begrenzte Dezimalkoordinaten

Der originale Overload behält seine Signatur und nutzt einen leeren Destination-Record; explizite Seitenziele erfordern Page-Count- und Page-Object-Callbacks

Dieser Low-Level-Callback-Mapper stellt selbst kein Whole-Document-Rollback bereit; SaveAnnotationsXFDFToFile für begrenzte Admission, authentifizierte Policy und atomare Datei-Veröffentlichung verwenden

Destination-Attribute und Limits

Der Standard-Stamp-Appearance-Transport bewahrt echte Form-Streams und begrenzte azyklische Font-, Bild- und Grafikressourcen über base64-typisiertes XML

function HPDFXFDFImportAnnotations(const Access: THPDFXFDFAccess;
  const Destinations: THPDFXFDFDestinationAccess; Root: THPDFXFDFNode;
  MaxAppearanceBytes, MaxAppearanceNodes, MaxAppearanceDepth: Integer;
  MaxAppearanceWorkingBytes: Int64;
  CancellationToken: THPDFCancellationToken): Integer; overload;

Limits sind positiv und kumulativ, mit einer Appearance-Tiefenobergrenze von 62; der frühere Overload liefert 16 MiB, 100000 Nodes, Tiefe 62 und 512 MiB Working-Reservation

Erzeugte indirekte Streams bleiben im Besitz des gelieferten Graph-Adapters; der Low-Level-Codec übernimmt kein Ownership des Aufrufer-Dokuments und stellt kein Whole-Operation-Rollback bereit

Der Adapter reserviert die originale Base64-Länge, einschließlich Whitespace, vor ANSI-Konvertierung und dekodierter Speicherung; RAW HEX und ASCII-Daten werden reserviert, bevor Stream-Byte-Arrays alloziert werden

Working-Reservationen sind konservativ und kumulativ für den kompletten Import, unabhängig von Output-Bytes; ein XFDF-Baum im Besitz des Aufrufers wird vom Aufrufer zugelassen, bevor dieser Adapter ihn konsumiert

Ein lexikalisches Preflight reserviert dekodierte XML-Knoten- und Attribut-Records sowie geerbte Namespace-Scope-Arrays, bevor der Baum konstruiert wird; Node-Count, Tiefe und Working Storage sind unabhängige kumulative Limits

Das AP-spezifische Preflight validiert das bestehende Objekt-Tag-Vokabular, bevor der gemeinsame XML-Reader aufgerufen wird, und bewahrt die Invalid-Type-Ablehnung, ohne unrelated XHTML-RawXML-Fragmente zu behalten