Cuando alguien descarga un artículo científico en PDF, la expectativa es razonable: el archivo se abre, se lee, se imprime. Nadie piensa demasiado en lo que hay adentro. Pero detrás de esa experiencia cotidiana existe una diferencia técnica significativa que tiene consecuencias reales para las editoriales académicas, sus repositorios y la preservación del conocimiento a largo plazo. Esta nota explica esa diferencia: entre el PDF que usamos para trabajar y el PDF/A-2b que debería ir a los repositorios institucionales.
1. Un poco de historia: el problema que el PDF/A vino a resolver
El formato PDF nació en 1993 como una solución de distribución de documentos. Su objetivo era simple: que un archivo se viera igual en cualquier máquina, independientemente del sistema operativo, la impresora o las fuentes instaladas. Era, fundamentalmente, un formato de intercambio.
Pero “verse igual hoy” y “verse igual en cincuenta años” son requisitos muy distintos.
A medida que las instituciones comenzaron a usar PDF para archivos legales, registros gubernamentales y publicaciones científicas, apareció una pregunta incómoda: ¿qué garantiza que un PDF generado en 2005 pueda reproducirse fielmente en 2055? Si el archivo referencia tipografías que ya no existen, o colores definidos para dispositivos que ya no se fabrican, o scripts que ya no corren, el documento puede quedar inutilizable.
Para resolver esto, la ISO publicó en 2005 el estándar ISO 19005-1, conocido como PDF/A. La “A” es de archiving: archivo a largo plazo. En 2011 publicó una segunda versión, ISO 19005-2, basada en PDF 1.7, que se denomina PDF/A-2. El nivel de conformidad “b” (de basic) define los requisitos mínimos para garantizar la reproducibilidad visual del documento. De ahí el nombre completo: PDF/A-2b.
El concepto central es la autocontención: un archivo PDF/A debe llevar consigo todo lo necesario para renderizarse correctamente, sin depender de ningún recurso externo. Sin fuentes del sistema. Sin perfiles de color de la impresora. Sin scripts. Sin cifrado que pueda bloquear el acceso futuro.
2. Qué tiene un PDF regular que no tiene PDF/A-2b, y viceversa
Conviene ser preciso sobre las diferencias técnicas, porque en la práctica editorial cotidiana se usan indistintamente términos que describen realidades distintas.
Fuentes tipográficas
Un PDF regular puede embeber las fuentes, pero no está obligado a hacerlo. Si el software que lo generó confía en que la fuente estará disponible en el sistema del lector, simplemente la referencia por nombre. Si esa fuente no está instalada en la máquina donde se abre el documento, el visor la sustituye por otra, y el documento cambia su apariencia.
Un PDF/A-2b exige que todas las fuentes utilizadas estén embebidas dentro del archivo. Sin excepción. El visor no necesita tener nada instalado: la tipografía viaja con el documento.
Esto tiene una consecuencia práctica importante para gbpublisher: LuaLaTeX con fontspec ya embebe todas las fuentes por defecto al compilar. Este requisito —el más difícil de cumplir en muchos flujos de trabajo— ya está resuelto por la cadena de producción habitual.
Espacios de color
Un PDF regular puede definir colores de manera dependiente del dispositivo: “este texto es RGB (45, 90, 178)”, que se interpretará de manera diferente en una pantalla calibrada, en un monitor barato y en una impresora. La reproducción exacta del color depende del hardware.
Un PDF/A-2b exige que todos los colores se especifiquen de manera independiente del dispositivo, mediante perfiles de color ICC. El estándar incluye además un OutputIntent: un perfil de color de destino, embebido en el archivo, que describe el espacio de color en el que el documento debe interpretarse. En la práctica, el perfil más utilizado es sRGB, ampliamente soportado y suficiente para documentos académicos que se distribuyen principalmente en pantalla.
Metadatos XMP
Un PDF regular puede tener metadatos —título, autor, fecha— pero su presencia es opcional, su formato no está estandarizado, y pueden estar en conflicto con los metadatos internos del archivo.
Un PDF/A-2b exige metadatos en formato XMP (Extensible Metadata Platform), el estándar de metadatos de Adobe, basado en RDF/XML. El archivo debe incluir, dentro del XMP, una declaración explícita de que es un PDF/A-2b. Esta declaración es parte del estándar: el archivo se anuncia a sí mismo como conforme.
Los metadatos XMP en un PDF/A-2b típico incluyen título, autores, palabras clave, resumen, fecha, idioma, editorial y DOI. Son legibles por máquinas sin necesidad de abrir el documento visualmente. Un repositorio puede extraerlos automáticamente.
Contenido externo y restricciones
Un PDF regular puede referenciar recursos externos: fuentes en servidores remotos, imágenes alojadas en URLs, scripts JavaScript, contenido multimedia con reproductores externos. Todo esto es incompatible con PDF/A.
Un PDF/A-2b prohíbe:
- Referencias a recursos externos
- Cifrado de cualquier tipo (porque podría impedir el acceso futuro)
- JavaScript
- Audio y video incrustado
- Acciones de apertura automatizada
PDF/A-2 (a diferencia de PDF/A-1) sí permite transparencia y capas de contenido opcional, lo que lo hace compatible con documentos con diseño más complejo sin necesidad de aplanar la transparencia.
3. Por qué esto importa en el contexto latinoamericano
Las revistas académicas de América Latina operan en un ecosistema de preservación que no siempre tiene los recursos técnicos de las grandes editoriales del norte global. SciELO, Redalyc, DOAJ y los repositorios institucionales de las universidades están comprometidos con el acceso abierto y la preservación del conocimiento producido en la región.
El argumento técnico del PDF/A se vuelve aquí especialmente relevante. Un artículo publicado por una revista de una universidad pública argentina, colombiana o mexicana tiene el mismo derecho a sobrevivir técnicamente durante décadas que uno publicado por Elsevier o Springer. El estándar no distingue por presupuesto.
Pero la realidad operativa es que muchas revistas de la región generan sus PDFs con flujos de trabajo que no controlan completamente: exportaciones desde Word, conversiones automáticas desde OJS, procesamiento en cadena sin verificación de conformidad. El resultado es un PDF que se ve bien hoy pero que no garantiza nada sobre mañana.
El PDF/A-2b no es un capricho burocrático: es una garantía técnica de que el conocimiento que se publica va a poder leerse en condiciones iguales a las actuales dentro de cincuenta años, en hardware y software que todavía no existen.
4. La decisión de diseño: por qué es una opción y no el comportamiento por defecto
gbpublisher genera PDF como salida de trabajo: borradores para revisión editorial, versiones finales para distribución en el sitio web de la revista, pruebas de diseño para corrección de estilo. Este PDF es el que el editor usa todos los días, en múltiples iteraciones, a veces decenas de veces por artículo.
Hacer que cada compilación genere un PDF/A-2b como comportamiento por defecto tendría un costo real. El proceso requiere una pasada adicional de LuaLaTeX para generar el archivo de control de Biber, la ejecución de Biber para procesar las referencias bibliográficas con los identificadores correctos, dos pasadas más de LuaLaTeX para resolver citas y referencias cruzadas, y la generación previa del archivo .xmpdata con los metadatos extraídos del canónico JATS. En total, una compilación PDF/A-2b implica cuatro ejecuciones de LuaLaTeX más una de Biber, frente a las tres de LuaLaTeX del PDF de trabajo.
Más allá del tiempo de compilación, existe otra razón de diseño: el PDF/A-2b corresponde a una etapa del proceso, no a todas. El PDF de trabajo es una herramienta de producción. El PDF/A-2b es una salida de archivo, que corresponde al momento en que el artículo está definitivamente aprobado y listo para depositarse en un repositorio institucional o enviarse a un indexador. Mezclar ambas funciones en una sola operación confunde los estadios del flujo editorial.
La separación es deliberada: gbpublisher produce el PDF de trabajo como parte del ciclo habitual de generación de salidas. Cuando el artículo llega a su versión final, el editor ejecuta el script pdfa-2b sobre el archivo activo, y obtiene un segundo PDF —identificable por el sufijo -pdfa— que coexiste con el PDF de trabajo sin reemplazarlo. Dos archivos con propósitos distintos, generados en momentos distintos del proceso.
5. Lo que ocurre técnicamente al generar el PDF/A-2b desde gbpublisher
El flujo es transparente al editor, pero vale la pena describirlo porque ilustra cómo se traduce el estándar a la práctica.
El script lee el archivo .tex generado por la cadena XSLT de gbpublisher y realiza dos modificaciones al preámbulo. Primero inserta el paquete de conformidad inmediatamente después de \documentclass:
\usepackage[a-2b,latxmp]{pdfx}
El paquete pdfx carga hyperref internamente con la configuración necesaria para la conformidad PDF/A. Para que los hipervínculos mantengan la apariencia visual del PDF de trabajo —color corporativo de la revista, enlaces coloreados en lugar de recuadros— el script agrega a continuación una segunda línea:
\hypersetup{colorlinks=true, linkcolor=azulrevista, citecolor=azulrevista,
urlcolor=azulrevista, filecolor=azulrevista, linktoc=all, breaklinks=true,
bookmarksopen=true, bookmarksnumbered=true}
Este paso adicional es necesario porque pdfx toma el control de hyperref antes de que el preámbulo original pueda configurarlo: si no se agrega explícitamente, los hipervínculos del PDF/A-2b tendrían la apariencia por defecto de hyperref en lugar de la configuración de la revista.
Antes de compilar, el script genera también un archivo .xmpdata extrayendo los metadatos directamente del canónico JATS del artículo: título, autores, palabras clave, resumen, DOI, idioma, fecha y editorial. Este archivo es el que pdfx usa para construir el bloque XMP incrustado en el PDF.
El paquete embebe el perfil sRGB como OutputIntent y declara la conformidad PDF/A-2b en el XMP. La fuente de los metadatos es siempre el canónico JATS, que en gbpublisher es la fuente autoritativa de todos los datos del artículo.
El resultado es un PDF que:
- Lleva todas las fuentes embebidas (Libertinus Serif, IBM Plex Sans Condensed, IBM Plex Mono)
- Define todos sus colores con el perfil sRGB embebido
- Contiene metadatos XMP con declaración explícita de conformidad PDF/A-2b
- No tiene contenido externo, cifrado ni scripts
- Es visualmente idéntico al PDF de trabajo, incluyendo el color de los hipervínculos
6. Verificación de conformidad: integración con veraPDF
Una cosa es generar un archivo que pretende ser PDF/A-2b. Otra es verificar que efectivamente lo es.
gbpublisher integra veraPDF, el validador de referencia para la familia de estándares ISO 19005, directamente en la interfaz. Una vez generado el PDF/A-2b, el editor puede validarlo desde la misma solapa donde opera el pipeline LaTeX, sin salir de la aplicación ni subir el archivo a ningún servicio externo. La validación corre localmente contra la instalación de veraPDF en /opt/verapdf/ y produce un informe con el mismo nivel de detalle que el validador en línea:
| Campo | Valor típico |
|---|---|
| Perfil de validación | PDF/A-2b validation profile |
| Conformidad ISO 19005-2 | PASSED |
| Reglas en el perfil | 144 |
| Verificaciones OK | 47671 |
| Verificaciones fallidas | 0 |
El informe incluye además el archivo validado con su tamaño, la versión de veraPDF utilizada, el tiempo de proceso y la declaración textual del validador. Si la conformidad falla, la fila correspondiente se colorea en rojo y el campo de detalle indica el comando para obtener el informe completo por consola.
Los iconos de redes sociales en el cabezal del artículo se procesan como archivos PDF pre-renderizados por Inkscape (formato PDF 1.5). Dado que PDF/A-2b se basa en PDF 1.7, estos recursos embebidos son plenamente compatibles con el estándar y no generan ninguna advertencia de conformidad.
Conclusión
El PDF que genera gbpublisher para el trabajo cotidiano y el PDF/A-2b que genera como opción de archivo son técnicamente distintos en cuatro dimensiones: fuentes (obligatoriamente embebidas), espacios de color (perfiles ICC independientes del dispositivo), metadatos (XMP estructurado con declaración de conformidad) y autocontención (sin referencias externas, sin cifrado, sin scripts). La diferencia no es visible en pantalla —ambos archivos tienen la misma apariencia— pero es la diferencia entre un documento que depende de su entorno para reproducirse fielmente y uno que lleva consigo todo lo necesario para existir de manera autónoma en cualquier contexto futuro.
Para una editorial académica latinoamericana, esa distinción tiene peso específico. El conocimiento que se produce en la región merece la misma garantía técnica de preservación que el que se produce en cualquier otra parte del mundo. El estándar existe, las herramientas están disponibles, y la decisión de usarlas está al alcance de cualquier equipo editorial que controle su propio flujo de producción.
