Destinations XFDF d'annotations

Le XFDF natif d'annotations, les jobs de fichiers Windows et les callbacks V1, ainsi que les callbacks V1 Linux natifs préservent les destinations nommées et les cibles de pages explicites locales dans les annotations Link, avec un chemin GoToR distant séparé

Un Dest direct mappe vers l'objet de destination PDF de l'annotation, tandis que OnActivation/Action/GoTo/Dest mappe vers une action GoTo locale ; l'index de page est à base zéro et est lié au véritable objet de page indirect lors de l'import

Le modèle d'attributs suit la XML Forms Data Format Specification, Version 3.0 d'Adobe, pages imprimées 59-68 et 88 ; la sémantique des destinations PDF est définie dans l'ISO 32000

L'export XYZ canonique omet les coordonnées dont l'objet PDF est null ; les coordonnées optionnelles manquantes préservent la coordonnée courante ou le zoom du lecteur, et le zoom zéro garde sa signification PDF standard

Le profil de compatibilité accepte aussi les attributs de coordonnées null littéraux et vides comme valeurs nulles ; les attributs requis FitH/FitV/FitBH/FitBV sont émis comme null littéraux quand leur objet PDF est null, sans prétention de certification du schéma ISO

FitR exige les quatre bornes numériques ; les attributs requis ne peuvent pas être omis des autres modes Fit, et Page doit être un entier décimal identifiant une page existante

Précision et bornes

Les noms d'éléments Adobe qualifiés et liaisons d'espaces de noms héritées préservent les mêmes cibles ; les espaces de noms de destination étrangers et les attributs XML dupliqués sont rejetés avant création d'annotation

Les coordonnées doivent être finies, avoir une valeur décimale absolue exacte d'au plus 1000000 et utiliser un zoom non négatif ; l'entrée numérique et la sortie décimale étendue sont limitées à 8192 caractères

Les décimaux signés et la notation scientifique sont acceptés dans ces limites, puis écrits comme jetons décimaux PDF sans notation exponentielle ; les jetons sources conservent la précision rédigée même quand la valeur Single publique legacy arrondit ou passe sous le minimum représentable

Le rechargement du PDF enregistré et l'export XFDF ultérieur préservent le jeton décimal conservé, fractions longues proches de la limite de coordonnées comprises

Transactions et callbacks

La transaction de fichier native valide les cibles avant publication, préserve le graphe chargé et la cible précédente en cas d'échec, et utilise les budgets existants d'annotations, d'objets, de profondeur, d'octets et de stockage de travail

Les points d'entrée JSON Windows et Linux utilisent le même codec mappé via leurs records d'opération V1 existants ; callbacks en échec ou annulation conservent le PDF précédemment commis, tandis que les puits de callbacks possédés par l'appelant peuvent avoir reçu des octets candidats

Un callback d'écriture en échec n'est pas réessayé via un puits de sortie ou de résultat aliasé ; la même règle s'applique à la comparaison à deux handles, et les valeurs de statut d'écriture indéfinies deviennent le statut d'erreur IO standard

Le codec partagé HPDFXFDF accepte un record de callbacks de destination séparé dans de nouvelles surcharges ; la disposition du record d'accès legacy reste inchangée

Les méthodes THotPDF d'annotations chargées lient ces callbacks automatiquement ; les appelants directs du codec doivent fournir le nombre de pages et la résolution de page pour les cibles explicites

Frontières

Ce profil mappe les données GoTo locales et de destination sans exécuter d'actions ; Launch, dictionnaires d'actions arbitraires, rédaction d'arbres de noms de destination, transport AP et remplacement ou suppression d'annotations restent des capacités distinctes

Profil d'annotations mappé · Opérations Windows · Callbacks Linux