Ir al contenido

PGD | §3.13 – La iniciativa PDF/X

§3.12 – Opciones de generación de un documento PDF

Si bien las ventajas mencionadas del formato PDF hicieron de éste el formato preferido de intercambio en gráfica, a medida que se popularizaba aparecieron varios inconvenientes, algunos de los cuales habíamos descripto anteriormente. En síntesis, las dificultades principales son:

  • Las opciones de generación de Distiller son tantas que, a partir de un diseño, es posible crear varios PDF sintácticamente correctos pero inadecuados para gráfica;
  • La naturaleza puramente descriptiva del formato eliminó la posibilidad (que PostScript conserva) de adjuntar parámetros adicionales para el dispositivo de destino, por ejemplo selección de medios, opciones de resolución, tramado, etc.

La segunda de estas objeciones se soluciona separando formalmente la descripción de la página de las instrucciones especiales recomendadas para su proceso. Aquí interviene un segundo formato de archivo que hace las veces de una ficha u orden de trabajo (job ticket). Con esta solución, se separa (al menos desde un punto de vista formal) la descripción de una página —vale decir, el contenido— de las variables de proceso que requiere un trabajo particular que emplee esa página. Así, es concebible que un mismo PDF pueda ser sometido a diferentes condiciones de impresión simplemente adjuntando en cada caso el “ticket” correspondiente.

Si bien este tema escapa al objetivo del curso, podemos resumir este punto como sigue:

  1. En 1993 Heidelberg comienza con la idea de definir un estándar para comunicar entre sí los diferentes procesos de la industria gráfica, para lo cual formó un consorcio denominado CIP3 (Cooperación Internacional para la integración de la Pre-impresión, Impresión y Post-impresión — International Cooperation for Integration of Pre-press, Press and Post-press).
  2. El primer resultado fue la creación de un formato de datos denominado PPF (Print Production Format).
  3. Casi simultáneamente, Adobe trabajaba de manera independiente en una idea similar a partir del concepto PDF llamada PJTF (Portable Job Ticket Format).
  4. En 1999 se llegó a un acuerdo por el cual se aceptaba que el éxito de un sistema que implementara la idea de una “orden de trabajo digital” sólo sería posible si el formato sobre el cual se basaba fuera abierto y estándar; como consecuencia, se delegó esta tarea al CIP3, ahora renombrado CIP4 (International Cooperation for the Integration of Processes in Pre-press, Press y Post-Press, por pretender ahora abarcar todos los procesos), conjuntamente con un nuevo formato basado en XML —que estaba siendo desarrollado por Adobe, Agfa, Heidelberg y MAN Roland—, denominado JDF (Job Definition Format).
  5. El objetivo del estándar consiste en que los sistemas que empleen JDF deben tener la capacidad de analizar, en cada etapa del proceso, los requisitos que deben cumplirse para realizar esa tarea (por ejemplo, cuáles archivos son necesarios y dónde encontrarlos), ejecutarla, actualizar la información sobre el trabajo hecho en el documento JDF, y enviar el resultado a la siguiente etapa, incluyendo las de terminación como encuadernación y armado en pallets.
  6. Aunque inicialmente estaba optimizada para impresión offset a pliego, JDF se ha expandido para incluir impresión digital, verificación (preflighting), impresión offset a bobina, packaging y diseño, entre otros.

El potencial del estándar es tal que algunos fabricantes desarrollan sistemas informáticos de gestión que son capaces de aprovechar la información recolectada en un documento JDF, por ejemplo para evaluar costos de producción, confeccionar presupuestos, monitorear la producción, etc.

Volviendo ahora a la primera objeción, el ingenio de los diferentes talleres de impresión ha producido diversos intentos de solución. Algunos de ellos eran:

  • Suministrar al cliente, mediante una descripción textual, capturas de pantalla u otro mecanismo similar, la información necesaria para que éste pudiera configurar las opciones de proceso del software empleado para la generación de los archivos PDF;
  • Suministrar al cliente el archivo de configuración de Acrobat Distiller (archivo .joboptions) para que con él configure su Distiller;
  • Enviar una persona con conocimientos a la ubicación del cliente para realizar la configuración por él.

Todas estas soluciones “funcionan” hasta cierto punto; sin embargo, tarde o temprano todas tropiezan con inconvenientes. Por ejemplo, la primera de las soluciones propuestas requiere que el cliente conozca el significado de cada una de las opciones indicadas para saber cuáles se aplican al software particular que esté empleando. La segunda solución no adolece de este problema; sin embargo, asume que el cliente utiliza Distiller para la generación del PDF —en lugar de una exportación desde la aplicación de diseño, por ejemplo—, y aún así el archivo .joboptions deberá actualizarse cada vez que cambie la versión del programa. La tercera solución exige contar con un experto que conozca todas las variantes (aplicaciones de diseño, versiones diferentes de Distiller, plataformas, etc.) para cubrir las posibilidades de los clientes.

La solución definitiva (con el alcance que puede tener esta palabra en cuestiones de tecnología) es “legislar” sobre la creación de un PDF, identificando un subconjunto limitado de objetos PDF y restringiendo el uso de dichos objetos, con el fin de lograr que, mientras tanto el que envía como el que recibe el documento utilice aplicaciones que sean conformes con estas restricciones, el documento, al ser impreso, sea exactamente lo que se pretendía, sin sorpresas y sin la necesidad de minuciosas conversaciones entre las partes para solucionar detalles. En otras palabras: lograr convertir a PDF en un formato de intercambio confiable (reliable eXchange) para las aplicaciones gráficas. En 1999, una iniciativa de un grupo de empresas dio por resultado la elaboración de un conjunto de restricciones con ese fin, que se denominaron normas PDF/X[1].

¿Hubo que esperar a la existencia de PDF para plantear la necesidad de un formato de intercambio estándar? No en realidad; existe un estándar previo de 1998 que utiliza TIFF como formato fundamental, conocido como TIFF/IT e internacionalmente denominado ISO 12639 (Graphic technology – Prepress digital data exchange – Tag Image File Format for Image Technology). Ha dado buenos resultados a la industria[2], pero está naturalmente restringido a pixeles; es decir, todos los objetos y textos deben convertirse a pixeles antes de poder intercambiarlos mediante TIFF/IT. Era necesario desarrollar un estándar basado en un formato que aceptara también objetos formados por curvas, también llamados vectoriales. La elección natural para este nuevo estándar era emplear un subconjunto de la especificación PDF que garantizara el intercambio confiable (de la misma manera que TIFF/IT es un subconjunto de la especificación TIFF). Las normas PDF/X son la descripción de ese subconjunto.

¿Es por lo tanto PDF/X un formato nuevo de archivo? No; un PDF/X puede abrirse y procesarse con cualquier aplicación que lo haga con un PDF cualquiera; un PDF/X es un PDF. Simplemente, en un PDF/X se han verificado ciertas condiciones durante su creación para garantizar su aptitud para determinados procesos.

§3.14 – Normas PDF/X: ISO 15930 >

1 Hablar de normas internacionales basadas en PDF tiene sentido desde que el formato dejó de ser propiedad de Adobe para convertirse él mismo en un formato estándar abierto e internacional desde el 1ro de julio de 2008, a través de la norma ISO 32000-1:2008 (PDF 1.7), y recientemente la flamante ISO 32000-2:2017 (PDF 2.0).
2 Hablamos, naturalmente, en los países desarrollados; en Argentina no llegó a materializarse.