PDF/A y PDF/X: el PDF para archivar, el PDF para imprimir y quién los exige de verdad

El PDF se ganó su fama con una promesa: el documento se ve igual en cualquier ordenador. En la práctica, esa promesa se rompe a menudo. Un PDF que nombra una fuente sin incrustarla se dibuja con la que el visor tenga a mano. Un formulario que estampa la fecha con JavaScript muestra una fecha distinta cada vez que se abre. Un PDF que carga una imagen desde una dirección web muestra un hueco en blanco cuando ese servidor desaparece.

PDF/A y PDF/X existen para tapar esos agujeros. Ninguno es un formato nuevo: cada uno es un subconjunto de PDF, una lista de funciones prohibidas y de funciones obligatorias. Lo que los separa es el propósito. PDF/A busca que el archivo se abra igual dentro de décadas. PDF/X busca que salga de la imprenta con los colores y el tamaño previstos.

Lo que PDF/A prohíbe y lo que exige

Casi todas las reglas de PDF/A salen de dos principios: no depender de nada que esté fuera del archivo y no dejar nada a la interpretación.

Todas las fuentes, incrustadas. El programa de fuente de cada glifo dibujado tiene que estar dentro del archivo, porque nadie sabe qué fuentes traerá un sistema operativo dentro de treinta años. Las llamadas 14 fuentes estándar, como Helvetica o Times, no son una excepción.

Cifrado prohibido. No solo la contraseña de apertura, también el cifrado de permisos que solo impide imprimir o copiar. Nada garantiza que un archivo histórico conozca la contraseña dentro de décadas, ni que exista software capaz de manejar ese esquema de cifrado. La norma entiende que el control de acceso corresponde al repositorio, no al archivo.

Color independiente del dispositivo. RGB 255, 0, 0 es un rojo distinto en cada monitor. PDF/A exige un OutputIntent con un perfil de color ICC o espacios de color basados en ICC, para que un visor del futuro sepa qué color representaban esos números.

Nada ejecutable. JavaScript, el lanzamiento de programas externos y el audio o vídeo incrustados quedan fuera. El documento tiene que ser lo que está dibujado y nada más.

Metadatos en XMP. Título, autor y la declaración de conformidad del archivo (parte y nivel pdfaid) se guardan como metadatos XML.

Este último punto genera un malentendido muy común. Cuando un visor muestra una barra diciendo que el documento cumple la norma PDF/A, o lo indica en las propiedades del archivo, solo ha leído esa declaración XMP. Cualquiera puede escribirla, y no escasean los archivos que la llevan sin tener las fuentes incrustadas. La conformidad solo se establece inspeccionando el contenido.

De la parte 1 a la 4

PDF/A es la norma ISO 19005, dividida en partes según la versión de PDF en la que se apoya.

Parte	Publicación	Base	Rasgos
PDF/A-1	2005	PDF 1.4	Sin transparencias, capas ni JPEG 2000. La más estricta y antigua
PDF/A-2	2011	PDF 1.7 (ISO 32000-1)	Admite transparencias, capas y JPEG 2000; puede adjuntar otros PDF/A
PDF/A-3	2012	PDF 1.7	Como la 2, pero admite adjuntos de cualquier tipo (XML, hojas de cálculo…)
PDF/A-4	2020	PDF 2.0 (ISO 32000-2)	Sustituye los niveles a/b/u por un perfil base, 4f (adjuntos) y 4e (ingeniería)

Las partes 1 a 3 llevan una letra de nivel. b (básico) garantiza solo la reproducción visual. u (desde la parte 2) añade la correspondencia Unicode de cada carácter para que buscar y copiar funcionen bien. a (accesible) añade una estructura de etiquetas para que un lector de pantalla conozca el orden de lectura, los títulos y las tablas.

PDF/A-3 nació de una necesidad concreta: enviar un solo archivo que lean las personas y procesen las máquinas. Las facturas electrónicas ZUGFeRD/Factur-X de Alemania y Francia hacen exactamente eso, con el XML de la factura incrustado en un PDF/A-3. Los archiveros tratan la parte 3 con cierta prudencia, porque nada garantiza que el XML o la hoja de cálculo adjuntos sigan siendo legibles.

El nivel importa sobre todo con los escaneos. Un PDF escaneado que solo contiene imágenes puede ser PDF/A-1b o 2b sin problema: no tiene fuentes ni transparencias. Pero no es buscable, así que donde se pida PDF/A con texto buscable hará falta una capa de OCR.

Quién exige PDF/A de verdad

Decir que «la Administración exige PDF/A» es demasiado genérico. Los requisitos que se pueden verificar suelen ir ligados a un momento concreto: presentar algo en un sistema determinado o transferir documentos a una institución determinada.

Juzgados españoles: LexNET. Es el caso más cercano para quien lee en español. El Real Decreto 1065/2015, que regula LexNET en el ámbito territorial del Ministerio de Justicia, dice en su anexo IV que el escrito o documento principal del envío deberá presentarse en formato PDF/A con la característica OCR. No fija parte ni nivel, pero sí exige texto buscable, de modo que un escaneo envuelto como PDF/A-1b sin reconocimiento de texto no cumple la letra de la norma. En la práctica, lo más seguro es exportar el escrito directamente desde el procesador de textos como PDF/A (el texto ya es texto, no imagen), firmarlo después y reservar el OCR para los documentos escaneados.

Registros federales de EE. UU. La NARA publica tablas con los formatos que acepta cuando las agencias le transfieren documentos electrónicos permanentes (boletín 2014-04). Para documentos textuales, PDF/A-1 y PDF/A-2 figuran como formatos preferidos y el PDF corriente (versiones 1.0 a 1.7) como aceptable.

Archivos públicos de Corea. El artículo 36.1 del reglamento de la ley coreana de gestión de archivos públicos obliga a las instituciones a convertir los documentos electrónicos con plazo de conservación de diez años o más a un formato de preservación documental y a un formato de preservación a largo plazo. En 2008 el Archivo Nacional de Corea adoptó PDF/A-1 como ese formato documental (según un estudio publicado en la revista coreana de archivística). Es una norma interna de conservación, no una obligación para los ciudadanos.

Lo que tienen en común es que esperan un archivo que supere la validación, no uno que simplemente declare ser PDF/A. Los sistemas de ingreso de los archivos validan en la transferencia y devuelven o reconvierten lo que falla.

PDF/X: lo que quiere la imprenta

PDF/X (ISO 15930) se ocupa de los accidentes de impresión, no de la conservación. Lo que más teme una imprenta es una fuente que cambia sin avisar, unos colores que no se parecen a los que el diseñador vio en pantalla y un filete blanco en el borde tras el corte.

Por eso PDF/X, igual que PDF/A, exige fuentes incrustadas y prohíbe el cifrado, pero sus reglas de color son más concretas. El OutputIntent debe identificar la condición de impresión para la que se preparó el archivo, con su perfil ICC: en Europa, y también en España, lo habitual son las condiciones FOGRA para offset; en Norteamérica, GRACoL o SWOP; en Japón, Japan Color. Cada página necesita además un TrimBox (tamaño final) y un BleedBox (dibujo extra más allá del corte para absorber el error de la guillotina), lo que en la imprenta se llama sangrado.

Las dos versiones más habituales se comportan de forma distinta:

PDF/X-1a:2001 exige todos los colores ya separados en CMYK y tintas planas, y prohíbe transparencias y capas. La imprenta recibe un archivo sin nada pendiente de decidir. Es la más compatible con flujos de salida antiguos.
PDF/X-4 conserva transparencias vivas, capas y color basado en ICC (RGB o Lab), y deja que el RIP del equipo de salida los resuelva para la máquina concreta. Así se evitan los filetes finos y el engrosamiento de texto que puede introducir el acoplado previo de transparencias, y es lo que recomiendan muchos flujos actuales.

Si las instrucciones de una imprenta dicen «enviar en PDF/X-1a», es señal de que su flujo no trata transparencias vivas. Mandar X-1a a quien acepta X-4 suele funcionar, con algún riesgo de defectos de acoplado.

En trabajos en blanco y negro también ayuda limpiar el color. Un documento diseñado en color y enviado a un proceso monocromo puede acabar con el texto negro impreso como negro enriquecido de cuatro tintas, que se empasta y gasta más. La herramienta PDF a escala de grises puede pasar páginas enteras a gris o dejar el texto negro en una sola tinta K.

PDF/A y accesibilidad

Como PDF/A-1a y 2a exigen etiquetas, es fácil tomarlas por «PDF accesible». Pero el nivel a comprueba sobre todo que exista una estructura. Verificar que las figuras tengan texto alternativo, que las tablas tengan celdas de encabezado y que los niveles de título no se salten es tarea de PDF/UA (ISO 14289), la norma específica de accesibilidad. No chocan entre sí: un mismo archivo puede declarar PDF/A-2a y PDF/UA-1.

Si los documentos de archivo también se publican en una web del sector público —sujeta en España al Real Decreto 1112/2018—, conviene pasar una comprobación de accesibilidad del PDF para etiquetas, idioma y textos alternativos, además de la validación de formato.

Convertir es fácil; validar es lo difícil

Hay muchas herramientas que «convierten» a PDF/A. La mayoría elimina lo prohibido y añade un OutputIntent y una declaración XMP, lo cual no es complicado. Lo difícil es ser honesto con lo que no se puede arreglar automáticamente. Una fuente que nunca se incrustó no se puede incrustar después sin el archivo de fuente original. En ese punto el conversor tiene dos opciones: informar del fallo o sustituir la página entera por una imagen de sí misma. La segunda pasa la validación pero tira a la basura el texto buscable, que en el caso de LexNET supone incumplir un requisito para cumplir otro.

Por eso la validación debe hacerla un verificador independiente del conversor. La herramienta libre de referencia es veraPDF, desarrollada por un consorcio encabezado por la Open Preservation Foundation y la PDF Association con financiación europea del proyecto PREFORMA. Informa de aprobado o suspenso por cada apartado de la ISO para todas las partes y niveles de PDF/A, y se ejecuta desde la línea de órdenes (verapdf --flavour 2b archivo.pdf), que es como los archivos validan transferencias masivas. Para PDF/X hay menos validadores gratuitos, y las imprentas suelen recurrir a verificaciones comerciales como Acrobat Preflight o callas pdfToolbox.

El conversor a PDF/A de este sitio vuelve a leer su propio resultado con un verificador separado que no comparte código con el conversor e informa apartado por apartado, pero hay cosas que no comprueba, como la coherencia de los anchos de glifo o los esquemas de extensión XMP. Si de ello depende una presentación, el último paso es veraPDF.

Un orden de trabajo práctico

Incrusta las fuentes al exportar. En las opciones de PDF de tu programa, activa la incrustación de fuentes y la opción PDF/A si existe. La mayoría de problemas que un conversor no puede resolver después desaparecen aquí.
Firma al final. La conversión a PDF/A reescribe el archivo e invalida cualquier firma anterior.
Comprueba qué parte y nivel pide el destinatario. Si no se especifica, 2b (o 2u si el texto debe ser buscable) es una buena opción.
Valida con una herramienta independiente. La barra «PDF/A» del visor no es una prueba.
Para imprenta, genera PDF/X con el perfil de tu imprenta. Un PDF/A de archivo pensado en sRGB, enviado tal cual a máquina, puede llegar con colores nunca convertidos para la condición de impresión real.