Opérations JSON et callback de suppression d'annotations

Les points d'entrée d'opérations C ABI Windows et Linux natifs acceptent annotations.remove ; le JSON de requête sélectionne les annotations, tandis que les octets PDF transitent par l'IO callback au lieu d'être incorporés dans le JSON

{
  "schemaVersion": 1,
  "type": "annotations.remove",
  "annotations": [{"page": 0, "name": "review-note"}],
  "annotationLimits": {
    "maxAnnotations": 4096,
    "maxOperations": 1000000,
    "maxNameBytes": 1048576,
    "maxWorkingBytes": 33554432
  }
}

annotations doit être un tableau d'objets contenant un page entier dans le document d'entrée réel et un name chaîne non vide ; les noms correspondent exactement au NM Unicode décodé

Un tableau vide ou des identités valides sans correspondance est une opération sans effet ; les sélecteurs dupliqués, les noms choisis ambigus, une propriété d'annotations mal formée et la sélection de widgets échouent

Cycle de vie d'entrée et de publication

Sans IO d'entrée, la suppression opère sur le document commité actuel du handle ; l'IO d'entrée explicite fournit un PDF indépendant et est préparée en privé au lieu de remplacer le contexte actuel avant le succès de l'opération

Fournissez password quand l'authentification d'une entrée chiffrée l'exige ; la permission d'annotation réelle et la politique des documents signés s'appliquent toujours

L'IO de sortie PDF et l'IO de résultat sont des puits distincts ; le moteur prépare le candidat, publie son PDF, publie le résultat JSON borné, vérifie l'annulation, puis seulement remplace le document actuel du handle

Un échec de lecture, d'écriture, de publication de résultat, de politique, de budget ou d'annulation conserve le contexte commité précédent et permet une nouvelle tentative normale sur ce handle

Un puits callback peut déjà contenir des octets quand une écriture ultérieure, un callback de résultat ou une annulation échoue ; un rollback de contexte ne peut pas rétracter ces octets externes, les appelants doivent donc préparer et publier leurs puits de manière transactionnelle

Une suppression répétée sur le résultat commité renvoie zéro et publie la révision actuelle exacte ; comparez la sortie callback seulement après avoir vérifié le statut de l'opération

Résultat et limites

Un résultat réussi comporte schemaVersion: 1, statusCode: 0, status: "ok", removed, mediaType: "application/pdf" et annotationProfile: "page-and-nm-removal-v1"

removed inclut les cascades de popups et de réponses, en comptant chaque annotation une seule fois même quand les dépendances forment un cycle

annotationLimits abaisse les capacités positives effectives décrites par THPDFHeadlessAnnotationRemovalOptions ; les limites de mémoire d'opération, d'objets, de pages, de sortie, de résultat et de temps écoulé restent indépendantes

La signaturePolicy optionnelle configure la politique CMS authentifiée existante, y compris les exigences CAdES, horodatages et confiance prises en charge par le point d'entrée d'opération

Les suppressions réelles sont soumises aux permissions d'annotations AES et à la politique de certification authentifiée P1/P2/P3 ; une vérification de mot de passe réussie ou un message d'erreur non signé ne prouvent ni permission ni certification de confiance

En cas d'échec, consultez le statut d'opération renvoyé et le résultat d'erreur structuré disponible ; un puits de résultat en échec peut empêcher la livraison d'un document JSON d'erreur complet

Voir la sémantique de suppression native et les jobs de fichiers Windows ordinaires