Annotation-XFDF-Destinations

Native Annotation-XFDF, Windows-Dateijobs und V1-Callbacks sowie native Linux-V1-Callbacks bewahren benannte Destinations und lokale explizite Seitenziele in Link-Annotationen, mit einem separaten Remote-GoToR-Pfad

Ein direktes Dest mappt auf das PDF-Destination-Objekt der Annotation, während OnActivation/Action/GoTo/Dest auf eine lokale GoTo-Action mappt; der Seitenindex ist nullbasiert und wird beim Import an das tatsächliche indirekte Seitenobjekt gebunden

Das Attributmodell folgt Adobes XML Forms Data Format Specification, Version 3.0, gedruckte Seiten 59-68 und 88; die PDF-Destination-Semantik ist in ISO 32000 definiert

Kanonischer XYZ-Export lässt Koordinaten weg, deren PDF-Objekt null ist; fehlende optionale Koordinaten bewahren die aktuelle Koordinate oder den Zoom des Viewers, und Zoom null behält die Standard-PDF-Bedeutung

Das Kompatibilitätsprofil akzeptiert auch literale null- und leere Koordinatenattribute als Nullwerte; erforderliche FitH/FitV/FitBH/FitBV-Attribute werden als literale null ausgegeben, wenn ihr PDF-Objekt null ist, ohne eine ISO-Schema-Zertifizierung zu behaupten

FitR verlangt alle vier numerischen Bounds; erforderliche Attribute können in anderen Fit-Modi nicht weggelassen werden, und Page muss eine Dezimalzahl sein, die eine existierende Seite bezeichnet

Präzision und Grenzen

Qualifizierte Adobe-Elementnamen und geerbte Namespace-Bindings bewahren dieselben Ziele; fremde Destination-Namespaces und doppelte XML-Attribute werden vor der Annotation-Erzeugung abgelehnt

Koordinaten müssen endlich sein, einen exakten absoluten Dezimalwert von höchstens 1000000 haben und nichtnegativen Zoom nutzen; numerische Eingabe und expandierte Dezimalausgabe sind auf 8192 Zeichen begrenzt

Vorzeichenbehaftete Dezimalzahlen und wissenschaftliche Notation werden innerhalb dieser Grenzen akzeptiert und dann als PDF-Dezimal-Tokens ohne Exponentnotation geschrieben; Quell-Tokens behalten authored Präzision, selbst wenn der öffentliche Legacy-Single-Wert rundet oder underflowt

Gespeichertes PDF-Reload und nachfolgender XFDF-Export bewahren das behaltene Dezimal-Token, einschließlich langer Brüche nahe dem Koordinatenlimit

Transaktionen und Callbacks

Die native Datei-Transaktion validiert Ziele vor der Veröffentlichung, bewahrt den geladenen Graphen und das vorherige Ziel bei Fehlern und nutzt die bestehenden Annotation-, Objekt-, Tiefen-, Byte- und Working-Storage-Budgets

Windows- und Linux-JSON-Einstiegspunkte nutzen denselben gemappten Codec über ihre bestehenden V1-Operation-Records; fehlgeschlagene Callbacks oder Abbruch behalten das zuvor committed PDF, während Callback-Senken des Aufrufers bereits Kandidaten-Bytes erhalten haben können

Ein fehlgeschlagener Write-Callback wird nicht über eine Alias-Output- oder Result-Senke wiederholt; dieselbe Regel gilt für den Zwei-Handle-Vergleich, und undefinierte Write-Status-Werte werden zum standardmäßigen IO-Error-Status

Der gemeinsame HPDFXFDF-Codec akzeptiert einen separaten Destination-Callback-Record in neuen Overloads; das Legacy-Access-Record-Layout bleibt unverändert

Die THotPDF-Loaded-Annotation-Methoden binden diese Callbacks automatisch; direkte Codec-Aufrufer müssen Page Count und Page Resolution für explizite Ziele liefern

Grenzen

Dieses Profil mappt lokale GoTo- und Destination-Daten, ohne Actions auszuführen; Launch, beliebige Action-Dictionaries, Destination-Name-Tree-Authoring, AP-Transport und Annotation-Ersetzung oder -Entfernung bleiben separate Fähigkeiten

Gemapptes Annotation-Profil · Windows-Operationen · Linux-Callbacks