Operações JSON e callback de remoção de anotações
Os entry points de operação do Windows e da C ABI nativa do Linux aceitam annotations.remove; o JSON de request seleciona anotações, enquanto os bytes do PDF viajam por IO de callback em vez de estarem embutidos no JSON
{
"schemaVersion": 1,
"type": "annotations.remove",
"annotations": [{"page": 0, "name": "review-note"}],
"annotationLimits": {
"maxAnnotations": 4096,
"maxOperations": 1000000,
"maxNameBytes": 1048576,
"maxWorkingBytes": 33554432
}
}annotations precisa ser um array de objetos contendo um page inteiro dentro do documento de entrada real e uma string name não vazia; nomes correspondem ao Unicode NM decodificado exatamente
Um array vazio ou identidades válidas sem correspondência é um no-op; seletores duplicados, nomes selecionados ambíguos, posse de anotações malformada e seleção de Widget falham
Ciclo de vida de entrada e publicação
Sem IO de entrada, a remoção opera no documento commitado atual do handle; IO de entrada explícito fornece um PDF independente e é staged privadamente em vez de substituir o contexto atual antes de a operação ter sucesso
Forneça password quando a autenticação da entrada criptografada exigir; permissão real de anotações e política do documento assinado continuam se aplicando
IO de saída de PDF e IO de resultado são sinks separados; o engine prepara o candidate, publica o PDF dele, publica o resultado JSON delimitado, checa cancelamento e só então substitui o documento atual do handle
Uma falha de leitura, escrita, publicação de resultado, política, budget ou cancelamento retém o contexto commitado anterior e permite retry normal naquele handle
Um sink de callback já pode conter bytes quando uma escrita posterior, callback de resultado ou cancelamento falha; rollback de contexto não pode retrair esses bytes externos, então callers precisam stagear e publicar seus próprios sinks transacionalmente
Remoção repetida contra o resultado commitado retorna zero e publica a revisão atual exata; compare a saída de callbacks só depois de checar o status da operação
Resultado e limites
Um resultado bem-sucedido tem schemaVersion: 1, statusCode: 0, status: "ok", removed, mediaType: "application/pdf" e annotationProfile: "page-and-nm-removal-v1"
removed inclui cascatas de popups e replies, contando cada anotação uma vez mesmo quando dependências formam um ciclo
annotationLimits abaixa as capacidades positivas efetivas descritas por THPDFHeadlessAnnotationRemovalOptions; limites de memória de operação, objetos, páginas, saída, resultado e tempo decorrido permanecem independentes
signaturePolicy opcional configura a política CMS autenticada existente, incluindo CAdES, timestamps e requisitos de trust exigidos suportados pelo entry point da operação
Remoções reais estão sujeitas a permissões de anotações AES e à política autenticada de certificação P1/P2/P3; um check de senha bem-sucedido ou uma mensagem de erro não assinada não é evidência de permissão nem de certificação confiável
Em caso de falha, chegue o status retornado da operação e o resultado estruturado de erro disponível; um sink de resultado com falha pode impedir a entrega de um documento JSON de erro completo