PDF/A, PDF/X y PDF/UA en Delphi: guía de HotPDF

PDF/A, PDF/X y PDF/UA son tres estándares distintos que resuelven tres problemas distintos: archivado a largo plazo, intercambio para imprenta y accesibilidad. No son tres casillas de un mismo formulario de conformidad, y el error más común es tratarlos como si lo fueran. Un archivo puede ser PDF/A impecable y resultar inútil para una imprenta; un máster de impresión perfecto puede ser ilegible para un lector de pantalla. Peor aún, los tres son restricciones sobre la estructura interna del archivo, no sobre su apariencia. Un documento que se abre sin problemas en todos los visores que usted tiene puede fallar igualmente la validación al primer intento, y suele hacerlo

HotPDF, la biblioteca PDF nativa en VCL de losLab, trata la conformidad como algo que usted declara antes de que exista la primera página. Usted establece una propiedad de conformidad, adjunta las estructuras que el estándar exige y la biblioteca rechaza al guardar las configuraciones que contradicen el perfil. Ese modelo es mejor que generar el archivo y confiar en que un posprocesador pueda adaptarlo después, porque la mayor parte de lo que estos estándares exigen no se puede agregar a posteriori

Tres estándares ISO, tres promesas distintas

PDF/A (ISO 19005) trata del tiempo. Promete que un archivo se seguirá representando igual dentro de décadas, así que exige autosuficiencia completa: todas las fuentes incrustadas, todo color con un significado independiente del dispositivo a través de un OutputIntent, metadatos XMP completos y la prohibición de cualquier cosa cuyo comportamiento dependa del entorno. El cifrado y JavaScript quedan fuera, porque nadie puede garantizar que el descifrador o el motor de scripts vayan a existir en 2050

PDF/X (ISO 15930) trata del color sobre papel. Existe para que un diseñador pueda entregar un archivo a una imprenta sin que ninguno de los dos tenga que discutirlo, lo que implica condiciones de impresión caracterizadas, una clave /Trapped obligatoria, geometría definida de corte y sangrado y, en la variante X-1a, nada de transparencia viva que el RIP tenga que adivinar. PDF/UA (ISO 14289) trata de quién puede leer el resultado. La tecnología de asistencia necesita un árbol de etiquetas completo, un orden de lectura sensato, un idioma de documento declarado y alternativas textuales para todo lo que no sea texto

Como los tres tiran en direcciones distintas, elija el estándar rector por canal de salida en lugar de perseguir un único archivo que satisfaga a todos. Un máster de impresión solo en CMYK es justo lo que no hay que entregarle a un usuario de lector de pantalla que nunca ve el color, y el bloqueo del comportamiento dinámico que impone el perfil de archivado choca con cualquier cosa interactiva. Genere por canal a partir de los mismos datos de origen y se ahorrará todo el conflicto

PDF/A: el OutputIntent es la parte que todos olvidan

Si un archivo PDF/A no pasa la validación, el OutputIntent es lo primero que hay que revisar. Es la estructura que los generadores omiten con más frecuencia, precisamente porque nada visible depende de ella. ISO 19005 exige una: un perfil ICC incrustado que fije qué significan realmente los colores de dispositivo del documento. HotPDF convierte ese perfil en una entrada explícita y no en algo secundario:

var
  Pdf: THotPDF;
  ICC: TFileStream;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := 'invoice-archival.pdf';
    Pdf.PDFACompliance := 'B';            // nivel B: fidelidad visual
    Pdf.Lang := 'en-US';
    Pdf.StandardFontEmulation := False;   // incrusta fuentes reales, sin emulación Base-14
    ICC := TFileStream.Create('sRGB.icc', fmOpenRead);
    try
      Pdf.AddPDFAOutputIntent('sRGB IEC61966-2.1', '', ICC, 3, 'DeviceRGB');
    finally
      ICC.Free;
    end;
    Pdf.BeginDoc;
    Pdf.CurrentPage.SetFont('Arial', [], 11);
    Pdf.CurrentPage.TextOut(50, 760, 0, 'Archival invoice body');
    Pdf.EndDoc;
  finally
    Pdf.Free;
  end;
end;

Aquí unos pocos detalles deciden si pasa o falla. StandardFontEmulation tiene que estar desactivado: las fuentes Base-14 emuladas no se incrustan, y la incrustación no es negociable bajo ISO 19005. El cifrado tiene que seguir deshabilitado, así que nunca combine PDFACompliance con ActivateProtection; un archivo de archivado cifrado es una contradicción que el validador detecta de inmediato. El número de componentes de AddPDFAOutputIntent debe coincidir con el perfil: 3 para un perfil RGB como sRGB IEC61966-2.1 y 4 para CMYK. HotPDF vigila el uso de DeviceRGB y DeviceCMYK frente al intent declarado mientras escribe, de modo que un relleno CMYK perdido en un documento con intent RGB se convierte en un problema reportado en lugar de silencioso

Vale la pena decir una cosa sobre el perfil ICC: trátelo como un artefacto de despliegue versionado, no como un archivo que alguien dejó una vez en el servidor de compilación. Sus bytes quedan incrustados en cada documento que usted genera, así que un perfil truncado o dañado envenena en silencio todo un lote, y usted se entera apenas en el momento de la validación. Distribúyalo con su instalador, registre su suma de verificación en la bitácora de ejecución y cárguelo con el patrón TFileStream mostrado arriba, para que un archivo faltante falle de forma ruidosa durante la generación y no en silencio en la puerta del archivo histórico

PDF/X para imprenta: Trapped, CMYK y el perfil de la prensa

Los másteres de impresión invierten la historia del color. La prensa quiere CMYK caracterizado, y el estándar lo obliga a usted a declarar si se aplicó trapping, incluso cuando la respuesta honesta es que no tiene idea. La clave /Trapped es obligatoria de todos modos:

Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown';        // clave obligatoria según ISO 15930
ICC := TFileStream.Create('FOGRA39.icc', fmOpenRead);
try
  Pdf.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICC, 4, 'DeviceCMYK');
finally
  ICC.Free;
end;
Pdf.BeginDoc;
// dibuje con colores seguros para CMYK, sin transparencia, sin cifrado
Pdf.EndDoc;

Ahora el número de componentes es 4 para el perfil CMYK de la prensa. X-1a además prohíbe la transparencia viva, así que audite todo el código de dibujo que superpone elementos translúcidos; lo que un visor compone en pantalla es exactamente lo que un RIP se negará a interpretar. Cuando su imprenta le envíe otra caracterización, cambie los bytes del perfil y la cadena identificadora, pero deje intacta la estructura circundante

PDF/UA: la estructura se genera, nunca se agrega después

La accesibilidad es el estándar que los equipos intentan acoplar al final con más frecuencia, y castiga ese enfoque más duro que los otros dos. El árbol de etiquetas tiene que reflejar el orden en que el contenido se creó lógicamente, que es información que usted sencillamente ya no tiene una vez escrito el archivo. Activar PDFUACompliance habilita la salida etiquetada, y la API de estructura vincula cada llamada de dibujo con su rol semántico sobre la marcha:

Pdf.PDFUACompliance := True;     // habilita automáticamente el PDF etiquetado
Pdf.Lang := 'en-US';             // establézcalo de forma explícita; si queda vacío, recae en 'en'
Pdf.BeginDoc;

Root := Pdf.AddStructureElement(sstDocument, nil);
H1 := Pdf.EmitTaggedHeading(1, Root, 50, 700, 'Quarterly Report');
Para := Pdf.BeginTaggedContent('P', Root);
Pdf.CurrentPage.TextOut(50, 650, 0, 'Revenue grew in all regions.');
Pdf.EndTaggedContent;

Pdf.EndDoc;

La falla que hay que vigilar es el texto dibujado fuera de cualquier par BeginTaggedContent/EndTaggedContent. Se representa a la perfección y queda invisible para un lector de pantalla, así que ningún probador vidente lo detecta jamás; el error se publica y aflora solo cuando un usuario real de tecnología de asistencia se topa con el hueco. Cuando sus plantillas lleven nombres de rol de estructura propios, asígnelos al conjunto estándar con AddStructRoleMap('MyHead', 'H1') para que los lectores conformes sepan qué significan. ISO 14289 también exige un idioma declarado. HotPDF recae en 'en' cuando Lang está vacío, pero eso es una red de seguridad, no una razón para dejar sin establecer el idioma real del documento

Verificación: confíe en el validador, no en el visor

Que un visor abra su archivo no prueba nada sobre la conformidad, así que la verificación pertenece a la ruta de publicación, con herramientas que revisan la estructura y no la representación. Para PDF/A y PDF/UA, veraPDF es el validador abierto de referencia; informa las fallas por cláusula ISO, lo que remite directamente a la configuración anterior. Para PDF/X, los perfiles Preflight de Adobe Acrobat siguen siendo la comprobación práctica, porque la conformidad de imprenta tiene tanto que ver con el intent de color como con la sintaxis

El generador cumple su parte. Al guardar, HotPDF concilia los indicadores de funciones con la versión de PDF configurada y degrada en silencio lo que esa versión no puede expresar, como AES-256 bajando a AES-128 por debajo de PDF 1.7. Las puertas de conformidad de EndDoc van más lejos y lanzan un error directo ante contradicciones duras, como pedir PDFACompliance junto con cifrado. Ninguna de las dos cosas reemplaza al validador externo. Solo impiden que configuraciones imposibles lleguen hasta él

Un hábito rinde una y otra vez: versione toda la configuración de conformidad como una unidad. La versión de HotPDF, la revisión de la plantilla, la suma de verificación del perfil ICC, la compilación del validador que dio el visto bueno. La conformidad se desvía apenas cualquiera de esos elementos cambia por debajo de los demás, y las auditorías más feas son aquellas en las que nadie puede reconstruir qué combinación produjo un archivo de hace cinco años. Un solo registro de configuración por lote resuelve eso para siempre

Por último, ejecute el validador sobre salida de producción real, nunca sobre una muestra prolija hecha a mano. Las fallas que muerden vienen de datos que nadie anticipó: un logotipo de cliente que llega en CMYK mientras el intent dice RGB, un retoque de plantilla que cuela una fuente sin incrustar, una nueva ruta de código que dibuja texto fuera del árbol de etiquetas. Conserve un archivo defectuoso conocido de cada incidente pasado como entrada de regresión y la puerta de conformidad se mantendrá honesta con el tiempo. Para el lado de la representación de estos flujos, vea nuestro artículo sobre salida de informes, fuentes e imágenes con HotPDF; para integrar validadores en una compilación, hay un artículo complementario sobre la automatización de las comprobaciones de preflight de PDF

Las propiedades de conformidad, los output intents y la API de etiquetado usados en estos ejemplos vienen con el HotPDF Delphi Component para Delphi y C++Builder; la página del producto enlaza la referencia completa de cada llamada mostrada aquí