Operações JSON e callbacks de remoção de anotações

Os entry points de operações do Windows e da ABI C nativa de Linux aceitam annotations.remove; o JSON de pedido seleciona anotações, enquanto os bytes do PDF viajam por IO de callbacks em vez de estarem incorporados no JSON

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

annotations tem de ser um array de objetos contendo um page inteiro dentro do documento de entrada real e uma string name não vazia; os nomes correspondem exatamente ao Unicode NM descodificado

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 Widgets falham

Ciclo de vida de entrada e publicação

Sem IO de entrada, a remoção opera no documento atual comprometido do handle; IO de entrada explícito fornece um PDF independente e é staged em privado em vez de substituir o contexto atual antes de a operação ter sucesso

Forneça password quando a autenticação da entrada cifrada o exigir; a permissão real de anotações e a política do documento assinado continuam a aplicar-se

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, verifica o 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 comprometido anterior e permite um retry normal naquele handle

Um sink de callbacks já pode conter bytes quando uma escrita posterior, callback de resultado ou cancelamento falha; o rollback de contexto não pode retrair esses bytes externos, por isso os callers têm de fazer stage e publicar os seus próprios sinks transacionalmente

Remoção repetida contra o resultado comprometido devolve zero e publica a revisão atual exata; compare a saída dos callbacks só depois de verificar 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 respostas, contando cada anotação uma vez mesmo quando as dependências formam um ciclo

annotationLimits baixa as capacidades positivas efetivas descritas por THPDFHeadlessAnnotationRemovalOptions; os limites de memória da 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

As remoções reais estão sujeitas a permissões de anotações AES e à política autenticada de certificação P1/P2/P3; uma verificação de palavra-passe bem-sucedida ou uma mensagem de erro não assinada não é evidência de permissão nem de certificação de confiança

Em caso de falha, verifique o status devolvido da operação e o resultado estruturado de erro disponível; um sink de resultado falhado pode impedir a entrega de um documento JSON de erro completo

Veja semântica nativa de remoção e file jobs comuns de Windows