Operaciones JSON y callback de eliminación de anotaciones

Los puntos de entrada de operaciones Windows y C ABI de Linux nativo aceptan annotations.remove; el JSON de solicitud selecciona anotaciones, mientras que los bytes PDF viajan por IO de callback en lugar de incrustarse en el JSON

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

annotations debe ser un arreglo de objetos con un page entero dentro del documento de entrada real y un name de cadena no vacío; los nombres coinciden exactamente con el NM Unicode decodificado

Un arreglo vacío o identidades válidas sin coincidencia es un no-op; selectores duplicados, nombres seleccionados ambiguos, propiedad de anotaciones malformed y selección de Widget fallan

Ciclo de vida de entrada y publicación

Sin IO de entrada, la eliminación opera sobre el documento confirmado actual del handle; la IO de entrada explícita suministra un PDF independiente y se prepara en privado en lugar de reemplazar el contexto actual antes de que la operación tenga éxito

Suministre password cuando la autenticación de la entrada cifrada lo requiera; el permiso real de anotaciones y la política de documentos firmados siguen aplicándose

La IO de salida PDF y la IO de resultado son sinks separados; el motor prepara el candidato, publica su PDF, publica el resultado JSON acotado, verifica la cancelación y solo entonces reemplaza el documento actual del handle

Una falla de lectura, escritura, publicación de resultado, política, presupuesto o cancelación retiene el contexto confirmado anterior y permite un reintento normal en ese handle

Un sink de callback ya puede contener bytes cuando una escritura posterior, el callback de resultado o la cancelación fallan; el rollback del contexto no puede retractar esos bytes externos, así que los callers deben preparar y publicar sus propios sinks de forma transaccional

La eliminación repetida contra el resultado confirmado devuelve cero y publica la revisión actual exacta; compare la salida del callback solo después de verificar el estado de la operación

Resultado y límites

Un resultado exitoso tiene schemaVersion: 1, statusCode: 0, status: "ok", removed, mediaType: "application/pdf" y annotationProfile: "page-and-nm-removal-v1"

removed incluye cascadas de popups y respuestas, contando cada anotación una sola vez incluso cuando las dependencias forman un ciclo

annotationLimits reduce las capacidades positivas efectivas descritas por THPDFHeadlessAnnotationRemovalOptions; los límites de memoria de operación, objetos, páginas, salida, resultado y tiempo transcurrido siguen siendo independientes

El signaturePolicy opcional configura la política CMS autenticada existente, incluidos CAdES requerido, timestamps y requisitos de confianza soportados por el punto de entrada de la operación

Las eliminaciones reales están sujetas a los permisos de anotaciones AES y a la política autenticada de certificación P1/P2/P3; una verificación de contraseña exitosa o un mensaje de error sin firma no son evidencia de permiso ni de certificación confiable

Ante una falla, verifique el estado de la operación devuelto y el resultado de error estructurado disponible; un sink de resultado fallido puede impedir la entrega de un documento JSON de error completo

Consulte la semántica de eliminación nativa y los file jobs de Windows ordinarios