Blog

Por qué dos validadores PDF/A son mejores que uno

Un resultado de conformidad PDF/A de un solo motor no basta como evidencia de auditoría. Por qué importa la validación con dos motores y cómo ejecutarla gratis en gpdf.com/validator/.

Un PDF cumple PDF/A-3 o no lo cumple. Entonces, ¿por qué alguien ejecutaría dos validadores sobre el mismo archivo?

Respuesta corta: porque la especificación es lo bastante grande como para que dos implementaciones correctas discrepen en los bordes, y un flujo con calidad de auditoría trata un “Pass” de un solo motor como luz amarilla, no como luz verde. Esta es la versión larga.

PDF/A es una pila de reglas negociadas, no un único algoritmo

PDF/A se define en varias partes de ISO 19005 (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), cada una con subniveles de conformidad (b, a, u, e, f), y todo ello se construye sobre la especificación PDF subyacente (ISO 32000). La superficie combinada suma varios miles de páginas de texto normativo.

Algunos ejemplos de puntos donde implementaciones conformes han divergido históricamente:

  • Transparencia en PDF/A-2/3: permitida bajo condiciones concretas; las condiciones están escritas de forma procedimental y distintos validadores implementan la comprobación de manera diferente.
  • Perfiles de color incrustados: ¿cuándo un perfil ICC es “obligatorio” y cuándo “recomendado”? Distintos validadores han marcado el mismo archivo como “Pass” y “Fail” en este eje.
  • Metadatos de archivos incrustados en PDF/A-3: AFRelationship, referencias /AF y XMP incrustado; las reglas están bien especificadas, pero varía la estrictez de aplicación.
  • Subconjuntos de fuentes: PDF/A exige que todas las fuentes estén incrustadas con su codificación real. Los casos límite con fuentes CID y subconjuntos parciales han provocado desacuerdos entre validadores.

Esto no siempre son bugs. Es la consecuencia natural de que una especificación compleja sea implementada por equipos independientes a partir de texto normativo. La posición conservadora — y la que adoptan la mayoría de industrias reguladas — es exigir varias confirmaciones independientes.

El motor de referencia y la segunda opinión

veraPDF es la implementación de referencia mantenida por la PDF Association, el organismo de estándares que publica PDF/A. Es open source, ha sido auditada por grupos de trabajo de la industria y su conjunto de reglas es la interpretación canónica del texto ISO 19005. Si veraPDF dice “Pass”, es la señal más fuerte que puede obtener de un solo motor.

Pero “la señal más fuerte de un solo motor” no es lo mismo que “evidencia que pasa una auditoría”. Auditores de instituciones reguladas — bancos, archivos sanitarios, oficinas de registros públicos — suelen exigir una segunda confirmación independiente porque:

  • la interpretación de una regla por veraPDF podría diferir de otro validador que el receptor usa internamente, lo que causaría un rechazo posterior;
  • un bug en cualquier motor individual, incluso el de referencia, no se detecta ejecutando dos veces ese mismo motor;
  • el principio de compras “dos confirmaciones independientes” se aplica ampliamente en dominios de cumplimiento; PDF/A hereda esa expectativa por sus casos de archivo.

La elección del segundo motor depende de lo que tenga disponible:

  • Adobe Acrobat Preflight es de pago y cerrado: válido como motor de confirmación, pero limita quién puede reverificar.
  • callas pdfaPilot es de pago y es la opción empresarial de facto, aunque también limita la reverificación independiente.
  • Un segundo motor open source: hay algunos, normalmente menos completos que veraPDF.

Lo que hicimos en gPdf fue construir nuestro propio motor en Rust + WebAssembly como una “reimplementación independiente” deliberada: misma especificación, mismas reglas, escrito desde cero por otro equipo. Cuando ambos motores aprueban el mismo archivo, la conclusión es mucho más fuerte que cualquiera de los dos por separado. Cuando discrepan, tiene un bug claro que investigar, ya sea en uno de los motores o en el archivo.

El validador que pone ambos en una sola URL

Alojamos ambos en gpdf.com/validator/: gratis, sin login. Ejecuta el archivo por veraPDF Y por nuestro motor en el edge en paralelo, y devuelve ambos informes lado a lado. Casos de uso:

  • Genera un PDF/A y quiere enviarlo: súbalo al validador, ambos pasan, adjunte los informes JSON como evidencia de QA. Listo.
  • Un motor falla y el otro pasa: tiene un bug preciso; compare los informes y encuentre el campo problemático. A menudo es algo sutil como un timestamp XMP desalineado o una referencia /AF ausente en un PDF/A-3.
  • Ambos fallan: el archivo está realmente roto; corríjalo en origen.
  • Auditoría de un lote de archivo entrante: suba PDF muestreados aleatoriamente, registre las URL de los informes y adjúntelas al papel de trabajo de auditoría. “Verificamos con veraPDF y con un motor independiente” es una afirmación más fuerte que “ejecutamos el checker de nuestro proveedor”.

El archivo que sube no sale de la solicitud: los motores se ejecutan en memoria sobre Cloudflare Workers y el archivo se descarta después de renderizar el informe. Sin login, sin persistencia, sin cuota.

El mismo patrón, generalizado

Esto no va solo de PDF/A. El patrón de “dos confirmaciones independientes” se extiende a:

  • Facturas electrónicas Factur-X / ZUGFeRD: gpdf.com/validator/ ejecuta Mustang (mustangproject.org) para el CII XML EN 16931 incrustado, junto con la comprobación PDF/A anterior. Validating ZUGFeRD with Mustang — what passes, what fails cubre ese flujo.
  • Certificados TLS: cada log moderno de una CA se comprueba con varios monitores.
  • Reproducibilidad de builds: dos reconstrucciones independientes desde la misma fuente deberían producir salidas idénticas byte a byte.

El mundo del cumplimiento lleva décadas haciendo esto. PDF/A simplemente se está poniendo al día.

TL;DR

Un “Pass” de un solo motor es luz amarilla. Un “Pass” de dos motores es luz verde. Ambos motores están gratis en validator: suba el archivo, obtenga dos informes y adjúntelos a su evidencia de QA. Si gPdf generó el archivo, el validador es el recibo público de que la API cumplió su promesa de conformidad.

Si está construyendo sobre la API de gPdf, la referencia de E-invoice API (§5) muestra cómo emitir Factur-X / ZUGFeRD PDF/A-3 directamente. Después, el validador lo confirma externamente. Dos motores, una subida: ese es el patrón con calidad de auditoría.