Boletin num. 51 - Especial Graphispag 2007
Seminario Taller "Impresión digital sin problemas"
Graphispag 2007: el gran encuentro
"Un revulsivo para reactivar la industria gráfica"
Novedades en Graphispag 07
JDF, ¿es la respuesta que estábamos esperando?
REPROnews

   
 

JDF, ¿Es la respuesta que estábamos esperando?

Desde la idea a su facturación el producto gráfico pasa por muchos procesos, algunos sucesivos, otros paralelos, muchos repetidos con suma de errores y complejidad de participantes, dentro y fuera del taller, en el intercambio de las tareas. A ordenar y solucionar este frecuente galimatías apunta JDF… ¿Lo conseguirá?. Por Manuel Gómez Güemes, gerente de Procograf y AG Consulting

 

Vamos a abordar un ejercicio tremendamente delicado: intentar explicar, de forma muy sencilla y para personas con una base técnica básica, qué se supone que es JDF (Job Definition Format) y qué va a aportar a nuestro quehacer diario. Pero, claro, este tipo de tareas "simplificadoras" han de hacerse respetando una premisa: la explicación ha de hacerse muy sencilla pero con rigor técnico. O sea, el clásico reto que presenta serios riesgos de acabar no gustando a expertos ni a profanos; y todo ello, en dos mil palabras. No gastaremos más en intenciones, pues, y vamos a intentar aportar con humildad, porque se ha escrito ya mucho acerca de este asunto, un poquito de claridad a personas que puedan sentirse agobiadas con tanta explicación basada en un sinfín de siglas.

 

Razones del JDF
Empezaremos por tratar de analizar qué partes de la actividad gráfica presentan anomalías que a todos nos gustaría subsanar; es decir, las razones por las que JDF puede ser útil.

Podemos aceptar que, desde que la idea de un producto gráfico toma cuerpo hasta que se entrega, se factura y se cobra, hay multitud de actividades que llegan a realizarse, muchas veces, en paralelo. Y podemos aceptar, sin dudarlo, que para ponerlas en contacto entre sí, muchas veces acostumbramos a hacerlo a través de instrucciones verbales o escritas, en base a lo que cada parte implicada pueda interpretar; esto genera, como mínimo, que haya que realizar muchas veces la misma tarea con no pocos errores en la cadena.

Si simplificamos, podemos decir que hay actividades relacionadas con la apariencia del producto (tamaño, forma, color…), sus costes (presupuestos, tarifas, tasas horarias…), la producción (calidad, coste, plazos…) control presupuestado/realizado, logística, contabilidad…que suelen constituir, todavía, una especie de mundos aislados entre sí. Los problemas, de uno u otro tipo, se plantean cuando necesitamos que la información y las instrucciones fluyan de un departamento a otro, o, lo que es peor, de una empresa a otra. Muchos de nuestros quebraderos de cabeza derivan de los errores que se producen en el intento, ya sea entre agencias/editoriales y talleres, secciones del propio taller, entre empresas de impresión, encuadernación, manipulado, etc.

Ese es el vacío que pretende llenar JDF; y lo va a hacer, ciertamente, aunque deberemos tener paciencia. La seguridad con la que hablamos proviene de que experiencias como CIP 3, que nadie conocía hace siete u ocho años, son hoy una agradable realidad, reduciendo tiempos de forma muy notable. Y lo hace en base a dos ideas que son simples: los datos que identifican al trabajo viajan en un formato llamado PJTF (Portable Job Ticket Format) y los que permiten el preajuste de las máquinas lo hacen en formato PPF (Print Production Format)

 

Qué es JDF
Ahora, la pregunta: ¿qué es JDF? Correré el riesgo de ser tachado de poco ortodoxo y diremos que es "un conjunto de especificaciones para manejar una serie de elementos (actividades, máquinas, programas…) de forma controlada, y que permitan obtener unos resultados perfectamente delimitados y previstos" Dicho así, parece claro que no es algo que vayamos a comprar como elemento aislado en un DVD, pero sí que tendrá que ser una posibilidad de equipos y programas. Y ya empezamos a manejar algunas de las siglas asociadas al JDF; la primera, en este caso, será ICS (Interoperability Conformance Specifications), que define una serie de requisitos para garantizar que dos elementos que las cumplan puedan operar entre sí.

 

Los componentes
Vamos a describir ahora los componentes del proceso: los agentes (agents), que pueden ser elementos de software, capaces de escribir en JDF; los controladores (controllers), que enviarán esta información a los llamados dispositivos (devices). Conviene aclarar que el controlador es más que nada una función que pueden realizar programas como los de gestión, por ejemplo. Los dispositivos deben ejecutar la información enviada por el controlador y poner en marcha el cuarto componente: la máquina (machine) que es el componente que ejecuta el trabajo.

Los componentes descritos conseguirán que se realicen todas las actividades necesarias para acabar un proceso, usando de dos conceptos: procesos (nodes) y recursos (resources) Imprimir sería un proceso que necesita de recursos de entrada como tintas, papel, planchas… y produce otros de salida, hojas impresas, que serán, a su vez, los recursos de un siguiente proceso.

 

Control de las relaciones
¿Quién controla las relaciones entre los componentes? El llamado MIS (Management Information System), que es el responsable de dar las instrucciones y comprobar que se ejecutan adecuadamente, para lo cual tienen que estar en permanente contacto con todos los elementos y medios implicados. En este momento, algunos de los programas que llamamos de gestión pretenden asumir o asumen este cometido.

¿Y la comunicación entre procesos y dispositivos? Se utiliza el llamado JMF (Job Messaging Format), que permite la comunicación de forma estándar. Sencillamente, el mensajero.

Y, por fin, ¿en qué se basa todo este complejo entramado? En algo tan conocido como el XML (eXtensible Markup Language) Los técnicos dicen de él que es un metalenguaje (lenguaje para definir lenguajes), no funcional sino descriptivo… ese tipo de cosas.

Para el propósito de este artículo, diremos que está orientado a identificar estructuras de datos en un documento. XML define la forma estándar de marcado de partes de un documento no estructurado para que se convierta en una determinada estructura de datos. Es decir, que mediante el marcado (etiquetado, podemos decir) se transforman los datos en información.

Lo que nos importa es que permite describir la información que necesitamos transmitir (con la estructura, relaciones y el uso que queramos darle) y que una buena parte de lenguajes de programación, aplicaciones de bases de datos, editores de texto… ya soportan XML.

De esta forma tan reducida, hemos intentado explicar el qué, por qué y cómo del JDF, esta nueva herramienta que es capaz de conectar entre sí todo aquello que ahora tenemos aislado. Esperamos haberlo conseguido.

 

Para saber más…

 

JDF: Desde la creación a la logística, un lenguaje común

Congreso graphispag_digital. Miércoles, 21 de febrero

     - CIP4 & JDF. Desarrollos técnicos (CIP4 Technical Overview).

     - Hacia JDF. Todo un camino por andar.

     - Las necesidades y posibilidades de la implantación de un entorno JDF.

     - JDF Expert Certificate Program

     - Casos reales de implantación de soluciones JDF en España