Operazioni JSON e callback di rimozione annotazioni

I punti di ingresso delle operazioni Windows e C ABI Linux native accettano annotations.remove; il JSON di richiesta seleziona le annotazioni, mentre i byte PDF viaggiano attraverso IO callback invece di essere incorporati nel JSON

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

annotations deve essere un array di oggetti contenenti un page intero dentro il documento di input effettivo e un name stringa non vuoto; i nomi corrispondono esattamente al NM Unicode decodificato

Un array vuoto o identità valide senza corrispondenza è un no-op; selettori duplicati, nomi selezionati ambigui, proprietà di annotazioni malformed e selezione di Widget falliscono

Ciclo di vita di input e pubblicazione

Senza IO di input, la rimozione opera sul documento confermato corrente dell'handle; l'IO di input esplicito fornisce un PDF indipendente e viene preparato privatamente invece di sostituire il contesto corrente prima che l'operazione abbia successo

Fornire password quando l'autenticazione dell'input cifrato lo richiede; il permesso effettivo di annotazione e la politica dei documenti firmati continuano ad applicarsi

L'IO di output PDF e l'IO del risultato sono sink separati; il motore prepara il candidato, pubblica il suo PDF, pubblica il risultato JSON limitato, verifica la cancellazione e solo allora sostituisce il documento corrente dell'handle

Un fallimento di lettura, scrittura, pubblicazione del risultato, politica, budget o cancellazione conserva il contesto confermato precedente e consente un normale tentativo su quell'handle

Un sink callback può già contenere byte quando una scrittura successiva, il callback del risultato o la cancellazione falliscono; il rollback del contesto non può retrarre quei byte esterni, quindi i caller devono preparare e pubblicare i propri sink in modo transazionale

La rimozione ripetuta contro il risultato confermato restituisce zero e pubblica la revisione corrente esatta; confrontare l'output del callback solo dopo aver verificato lo stato dell'operazione

Risultato e limiti

Un risultato riuscito ha schemaVersion: 1, statusCode: 0, status: "ok", removed, mediaType: "application/pdf" e annotationProfile: "page-and-nm-removal-v1"

removed include le cascata di popup e risposte, contando ogni annotazione una sola volta anche quando le dipendenze formano un ciclo

annotationLimits abbassa le capacità positive effettive descritte da THPDFHeadlessAnnotationRemovalOptions; i limiti di memoria dell'operazione, oggetti, pagine, output, risultato e tempo trascorso restano indipendenti

Il signaturePolicy opzionale configura la politica CMS autenticata esistente, inclusi CAdES richiesto, timestamp e requisiti di trust supportati dal punto di ingresso dell'operazione

Le rimozioni effettive sono soggette ai permessi di annotazione AES e alla politica autenticata di certificazione P1/P2/P3; una verifica password riuscita o un messaggio di errore non firmato non sono prova di permesso o di certificazione affidabile

In caso di fallimento, verificare lo stato dell'operazione restituito e il risultato di errore strutturato disponibile; un sink del risultato fallito può impedire la consegna di un documento JSON di errore completo

Vedere la semantica di rimozione nativa e i file job Windows ordinari