eskoartwork extends backstage with view, compare and data … · 2008-09-15 · eskoartwork...

ESKOARTWORK BACKSTAGE ‘PRODUCTS’ & BACKSTAGE VIEWER FACTSHEET

EskoArtwork extends BackStage with view, compare and data management tools 1

BackStage Products: Optimized Job and data management Image 1: Concept and business logic

BackStage already had a ‘Jobs’ database that matches the order entry database of the Admin

system. In BackStage, these (blue) Jobs represent the Job-orders that are active for prepress

production. Products are the individual print objects that belong to one job. Thus the new BackStage

Products tool is the database representing the Products that can be ordered within those Job-orders.

An

1 Note: All screenshots presented are from the BackStage Pilot, the BackStage client interface that is available on both Mac and Windows.

EG_pr585hius_BackStage-Factsheet_LR

September 9, 2008

1 / 15



September 9, 2008

2 / 15

example to illustrate the concept: The BackStage Jobs database might show 77 active Jobs to do.

The BackStage Products database might store 20.000 final one-up production PDFs. These

production assets were made BackStage Products because they are likely to be used within these

77 current or any future Job-orders.

Almost all prepress production operators still get a paper printout of the job-to-do: this paper

specifies what to do with which Products. That information is now more than ever translatable in the

application they use daily. This Products tool brings them another step closer to fully digital

communication on Job processing; a lot more productive than the paper and file based production

until now.

Image 2: The BackStage Products gallery

The BackStage Product gallery shows all Products in the database. The thumbnail interface can be

switched for a list view, with more details on the Product’s properties. The colour bar indicates a

status, typically related to approval or any other custom status. This image shows a filtered view of

all products from customer ‘Funky’. Custom filters can be made, e.g. all approved adhesive front

labels of customer ‘Funky’. A database is smarter and faster than the extensive searching and file



September 9, 2008

3 / 15

naming they typically use now. BackStage operators were already used to the Job-order database,

this Product tool provide an enhancement to the way they worked before. They got used to easily

finding the Job-at-hand, now they will enjoy easily finding the Product files to use.

To the BackStage user, probably a converter, a BackStage Product represents a finished Product.

The converter can receive an order for this Product. Example: a printer of labels for beer bottles

might get an order to (re)print 24.000 front labels, 24.000 neck labels, 12.000 French back labels

and 12.000 Spanish back labels. That is why, to the converter, these are 4 Products, 4 unique

labels. The converter’s end customer - the brand owner - calls the filled bottle with the 3 labels his

‘product’. Admin and production applications at converters also use other synonyms for what we call

BackStage Products: items, article, SKU (Stock Keeping Unit).

Image 3: BackStage Products are linked to BackStage Jobs

The image shows how an operator has linked 4 fruit juice label products into the BackStage Job

‘66789’. He has read on his job sheet that this order is about those 4 Products ; he will now read the

further instructions on output. He is offered his favorite tasks to launch and he sees the tasks that

were already run in the context of that Job.



September 9, 2008

4 / 15

This is where the main benefit comes in: When the operator ‘links’ these 4 Products into that Job-

order, he does not copy those data, he only makes links between the 2 databases. In stead of

copies, he can now work with these fast shortcuts. The data visually belong to the Job-order, but

there was no more need for physical copies. Useless copies only create more need for disk storage

and add confusion to which version really is the latest agreed final version and to which version was

‘really’ used in Job XYZ etc..

These are the classic type of Job orders at converters:

The simplest form of this Job would be that it is a re-run of 4 existing labels. Then the

operator just needs to, without any approval cycle, Step&Repeat them and send that plate

layout to the RIP. Many call this order type a Re-Run No Change (RRNC).

A Job order could also request a minor change to one or multiple of these products. A

change can be so small that it is decided that it would not lead to considering the new file

as another product: the operator will be allowed to overwrite the production file. For

example: Move that juice name 1 mm to the left. This Re-Run With Change (RRWC) might

call for a new approval cycle as well.

If it is agreed that the change does lead to a new design (one that needs to be separate

from the previous one), then a new Product will be created. Example: an updated logo or

image or text change. The name (usually a number) of this new Product (a new variant

actually) can be decided by the MIS or even in prepress. If the old design may never be re-

ordered again, this can be a reason to remove it from the Product database (or one could

keep it in there and give it a custom status ‘outdated’).

Another scenario is that the Job is about 1 or more *new* Products, or a mix of any of the

above type of orders. This is where the operator will first make the design print ready

(correct separations, add bar code, trapping, correct trim/die shape etc..) and then he will

promote this production file to become a real BackStage Product. This can be done

manually or can be part of the workflow automation tasks.

The editing applications PackEdge (one-up editing) and Plato (plate layout) are already integrated

with this Products concept: the operator will be guided to the relevant product files in the Job he is

working in. This integration will be done in ArtPro as well. In Plato, where you will want to

Step&Repeat the Products of the Job, the grid menu will offer to load specific or all Products of the

Job. Again, no more need for the Plate layout operator to searching and browsing to find the correct

asset.



September 9, 2008

5 / 15

Image 4: Product ‘parts’

A Product can have multiple Product ‘parts’. A typical example is labels that have both recto and

verso print. These 2 sides may link to 2 different production PDFs, but after several print stages or

even after finishing, they might end up as 1 Product in the warehouse of the converter. Another

example of 1 Product existing of several ‘parts’ is a back label with a booklet glued to it.



September 9, 2008

6 / 15

Image 5: properties of a Product

This Product has 2 parts. The general Product properties are shown here (‘Product setup’): of

course the name and ID, the customer and the name the customer gives this product, custom fields

for categorization and filtering, a free-text description and the status (if similar for all its parts).



September 9, 2008

7 / 15

Image 6 & 7: properties of a part a Product

This image shows the properties of the first Product part. The tab ‘Status’ is selected. See the status

that this part is approved. A Product part can be approved manually or automatically in case the

approval was requested on WebCenter.



September 9, 2008

8 / 15

This image shows the properties of part 2 of the Product. The tab ‘Barcode’ is selected. The bar

code can be checked and forced in background by a dedicated task.


Image 8: effect on data structure

The fact that you no longer have to copy the one-up data into a folder representing the Job-order

opens the possibility to organize the data server in a different way. The interface for the operator

now mainly consists of the databases, and a lot less of the disk tree structure. Since early DTP-

days, production sites have ‘managed; the best they can to optimize the data organization: often

they got used to limitations because there was simply no other way (read; no database concept).

That is why many have turned to and lived with copying data, that is why many have invented

procedure of naming files and folders as there were no other ways of showing the properties of the

file.

Another effect becomes clear as well: Job-orders are temporary, their data lives as long as the order

is active (days to weeks), rather short term. Product data is long term data: the folder with all those

production assets is the ‘vault’ of the prepress department. Plate layouts and RIP data can be short

or long term data, BackStage supports both choices.


September 9, 2008

9 / 15



September 9, 2008

10 / 15

BackStage was always very lenient to the existing data structure; now, with the Products tool, even

more. Customers using this Product tool are suggested to split the data belonging to Jobs from the

data belonging to the Product. Now, when a Product belongs to a Job, the simple linking between

the databases will make the connection, so you can finally split these data trees now and maybe

even give them a different backup and archive procedure. Logic would be to archive Job data but

keep Product data online.

JDF/JMF integration

A one-up production asset can be made a BackStage Product in several ways: • manual (via the ‘Add to Products’ task, maybe together with 200 other assets, located with a

smart find tool) • or via JDF/JMF.

BackStage Jobs are already created via JDF/JMF since many years. Almost 10% of BackStage users have already enabled this integration with their MIS (a custom build system or a commercially available MIS product). The next obvious thing is to not only have the BackStage Job created (with its blue Job Folder and with the Job-order parameters like customer name, due-date etc..), but to also receive via JDF/JMF the names of the Products involved in that Job. This is a major piece of information in the Job definition that was until now not digitally ‘forwarded’. A JDF/JMF command can not just refer to an existing item in the BackStage Product database, but can even create a New Product. BackStage will create it in its product database and show an empty thumbnail. Prepress will then later attach the right asset to that Product. EskoArtwork is working with several MIS vendors to enable this in their JDF/JMF exports.

The BackStage Products tool is in beta since v 7.0 Release 4 (released August 2008). It will be

customer released in v 7.0 Release 5.



September 9, 2008

11 / 15

BackStage Viewer: an amazing View and Compare tool Image 1: The BackStage Viewer is started from a BackStage Pilot client (Mac/Windows)

If the BackStage Viewer is able to open the file, the View column will offer a hyperlink to open the file.



September 9, 2008

12 / 15

Image 2: Take advantage of unlimited zoom-in and detailed measure tools

The original file (left) contains trapping, the reference file (right) does not. Trapping is 0,3 mm. Image 3: Analyze separations in several view modes



September 9, 2008

13 / 15

Image 4 & 5: Compare and analyse the differences

The image shows a typical difference after a file was made print ready. In this use case, the user will

expect differences, but he will here check for *unwanted* differences. Sure he knows that some text

was moved that the barcode was added and that the file was trapped, but why is that logo below

right different? The accidental knock-out attribute of the logo is the error that the user will be happy

to have discovered here and not on plate, or even worse, on press.

The above image shows the differences in highlight mode; the user can also choose to see

‘differences only’ (below) or choose to see the files side by side.



September 9, 2008

14 / 15

Image 6 & 7: Comparing a RIPped plate with one-up PDF!

BackStage’s ability to read so many prepress formats knows becomes clear in its client Viewer as well. One of the amazing aspects of this Viewer is its file support.



September 9, 2008

15 / 15

These file formats can be opened in the BackStage Viewer:

• Graphics o Esko Normalized PDF (one-up), PDFPLA (plate layout) o ArtPro o PDF o EPS/PS, DCS/EPS o AI - Adobe® Illustrator® (when PDF compatible) o Legacy Esko formats GRS, PLA and EPF

• Image data o PSD – Adobe® Photoshop® o EPS o TIFF (< 600 ppi) o Legacy Esko CT

• RIP data o 1 bit TIFF > 600 ppi , LEN o Greyscale o DCS 2.0 > 600 ppi

And when opened, any file can be compared to any other file open. Some examples:

• Initial AI design file with final production file (PDF or ArtPro) • Comparing versions or variants of production files • Comparing Stepped and Ripped output to one up or stepped PDF/ArtPro • Etc…

The BackStage Viewer is part of the Power pack module and was released in BackStage v 7.0 Release 4

BACKSTAGE ‘PRODUCTS’ DE ESKOARTWORK Y HOJA DE DATOS DE BACKSTAGE VIEWER

EskoArtwork amplía BackStage con herramientas de visualización, comparación y administración de datos 1

BackStage Products: optimización de la gestión de datos y trabajos Imagen 1: concepto y lógica de negocio

BackStage ya tenía una base de datos de “trabajos” que se correspondía con la base de datos de

entrada de pedidos del sistema de administración. En BackStage, estos trabajos (azules)

representan los pedidos de trabajo activos para la producción en el departamento de preimpresión.

Los productos son los objetos de impresión individuales que corresponden a un trabajo. En

consecuencia, la nueva herramienta BackStage Products es la base de datos que representa los

productos que se pueden pedir dentro de los pedidos de trabajo.

1 Nota: Todas las fotos de pantalla que se muestran corresponden a BackStage Pilot, la interfaz cliente de BackStage disponible para Mac y Windows. EG_pr585hies_BackStage-Factsheet

Septiembre 2008 1 / 15


EG_pr585hies_BackStage-Factsheet


Un ejemplo para ilustrar el concepto: la base de datos de trabajos “BackStage Jobs” podría indicar

que hay 77 trabajos activos pendientes. La base de datos de productos “BackStage Products”

puede almacenar 20.000 archivos PDF unitarios de producción. Estos recursos de producción se

han convertido en productos de Backstage porque es probable que se utilicen en los 77 trabajos

actuales o en cualquier pedido de trabajo futuro.

Casi todos los operarios de preimpresión siguen recibiendo una versión en papel del trabajo por

hacer, en la que se especifica qué se debe hacer con cada uno de los productos. Ahora, esta

información es todavía más fácilmente trasladable a la aplicación que utilizan a diario. BackStage

Products les acerca un paso más hacia la comunicación totalmente digital para el procesamiento de

trabajos, que resulta mucho más productiva que la producción basada en papeles y archivos que se

venía utilizando hasta ahora.

Imagen 2: la galería de productos Backstage

La galería de productos BackStage muestra todos los productos de la base de datos. La interfaz

basada en miniaturas se puede cambiar por una vista en forma de lista que muestra más detalles

sobre las propiedades del producto. La barra de color indica un estado, por lo general relacionado

con la aprobación u otro estado personalizado. Esta imagen muestra una vista filtrada de todos los

productos del cliente “Funky”. Es posible crear filtros personalizados, por ejemplo: todas etiquetas




frontales adhesivas aprobadas del cliente “Funky”. Una base de datos es más inteligente y más

rápida que el sistema de búsqueda y nomenclatura de archivos que suele emplearse actualmente.

Los operarios de BackStage ya estaban acostumbrados a la base de datos de trabajos y esta

herramienta de productos supone una mejora en su forma de trabajar. Si se acostumbraron a

encontrar fácilmente el trabajo en curso, ahora disfrutarán pudiendo encontrar los archivos de

productos que se utilizarán en el trabajo.

Para el usuario de BackStage, que probablemente será un convertidor, un Producto BackStage

representa un producto acabado. El convertidor puede recibir un pedido de este producto. Ejemplo:

un impresor de etiquetas para botellas de cerveza puede recibir un pedido para (re)imprimir 24.000

etiquetas frontales, 24.000 etiquetas de cuello, 12.000 etiquetas posteriores en francés y otras

12.000 en español. Por ese motivo, para el convertidor, se trata de 4 productos, 4 etiquetas

diferentes. El cliente final, el propietario de la marca, considera la botella rellena con las 3 etiquetas

su “producto”. Las aplicaciones de administración y producción de las empresas de conversión

también utilizan otros sinónimos para lo que nosotros llamamos productos de BackStage:

componentes, artículos, unidades de referencia o SKU (Stock Keeping Unit).

Imagen 3: los productos de BackStage están vinculados con los trabajos de Backstage

Esta imagen muestra cómo un operario ha vinculado 4 productos de una etiqueta de un zumo de

frutas al trabajo de BackStage “66789”. Ha leído en la hoja de trabajo que el pedido abarca estos 4

productos; ahora leerá las demás instrucciones sobre la impresión. El programa le permite iniciar

sus tareas favoritas y puede ver las tareas que ya se han ejecutado en el contexto de este trabajo.

Aquí es donde entra en juego la

ventaja principal de esta

herramienta: cuando el operario

“vincula” estos 4 productos al

pedido de trabajo, no copia los

datos sino que crea enlaces entre

2 bases de datos. En lugar de

usar copias, puede trabajar con

estos atajos rápidos. Los datos

pertenecen visualmente al pedido

de trabajo, pero ya no se




necesitan copias físicas. Las copias inútiles sólo exigen más espacio de almacenamiento en disco y

añaden confusión sobre la versión que se considera final y la versión que “realmente” se ha

utilizado en el trabajo XYZ, etc.

Estos son los típicos pedidos de trabajo de una empresa de conversión:

La forma más sencilla del trabajo sería una reimpresión de 4 etiquetas existentes. En ese

caso, lo único que debe hacer el operario, sin ningún ciclo de aprobación, es montarlas

por repetición y enviar el diseño de la plancha al RIP. Muchos llaman a este tipo de

pedido un Re-Run No Change (RRNC).

Un pedido de trabajo también puede solicitar un pequeño cambio en uno o varios de los

productos. El cambio puede ser tan insignificante que se decida que no cabe considerar el

nuevo archivo como otro producto, en cuyo caso el operario podrá sobrescribir el archivo

de producción. Por ejemplo: mover el nombre del zumo 1 mm hacia la izquierda. Este

trabajo Re-Run With Change (RRWC) también puede exigir un nuevo ciclo de aprobación.

Si se acuerda que el cambio sí que implica un nuevo diseño (uno que deba separarse del

anterior), se creará un nuevo producto. Ejemplo: la actualización de un logotipo o imagen

o un cambio de texto. El nombre (normalmente, un número) del nuevo producto (en

realidad una nueva variante) se puede decidir a través del sistema MIS o incluso en el

departamento de preimpresión. Si el diseño anterior no se vuelve a pedir, puede ser

motivo suficiente para eliminarlo de la base de datos de productos (o mantenerlo allí y

asignarle el estado personalizado “caducado”).

Otra posibilidad es que el trabajo trate sobre 1 o más productos *nuevos*, o una

combinación de los tipos de pedidos anteriores. En ese caso, el operario se encargará

primero de dejar el diseño listo para imprenta (separaciones, códigos de barras, solapado,

forma de corte/troquel, etc.) y posteriormente promocionará el archivo para convertirlo en

un producto BackStage. Este proceso puede ser manual o puede formar parte de las

tareas de automatización del flujo de trabajo.

Las aplicaciones de edición PackEdge (edición de páginas unitarias) y Plato (diseño de planchas)

ya están integradas en este concepto de productos: se remitirá al operario a los archivos de

productos relevantes del trabajo en el que está trabajando. Esta integración también se llevará a

cabo en ArtPro. En Plato, donde puede ser necesario montar por repetición los productos, el menú

ofrecerá al usuario la posibilidad de cargar algunos o todos los productos de un trabajo. El operario

encargado del diseño ya no tendrá que buscar hasta encontrar el recurso correcto.




Imagen 4: “Partes” de un producto

Un producto puede tener múltiples “partes” (“Parts”) de productos. El típico ejemplo son las

etiquetas que tienen impresión en recto y verso. Las 2 caras pueden estar vinculadas a distintos

archivos PDF de producción, pero después de varias fases de impresión o incluso después del

acabado, pueden terminar siendo un solo producto en el almacén. Otro ejemplo de 1 producto

formado a partir de varias “partes” es una etiqueta trasera con un folleto pegado.




Imagen 5: propiedades de un producto

Este producto tiene 2 partes. Aquí se muestran las propiedades generales del producto (“Product

setup”): por supuesto, el nombre y la ID, el cliente y el nombre que el cliente ha dado al producto,

campos personalizados para categorización y filtrado, una descripción libre y el estado (si es similar

para todas sus partes).




Imagen 6 y 7: propiedades de una parte de un producto

Esta imagen muestra las propiedades de la primera parte de un producto. Se ha seleccionado la

ficha “Status”. En el estado se puede observar que la parte ha sido aprobada. Una parte de un

producto se puede aprobar manual o automáticamente en el supuesto de que se haya solicitado la

aprobación desde WebCenter.




Esta imagen muestra las propiedades de la segunda parte del producto. Se ha seleccionado la ficha

“Barcode”. Con la tarea adecuada se puede comprobar y forzar a segundo plano el código de

barras.


Imagen 8: efecto sobre la estructura de datos

El hecho de no tener que copiar los datos unitarios de cada página en una carpeta que represente

el pedido de trabajo, ofrece la posibilidad de organizar el servidor de datos de otra forma.

Actualmente la interfaz del operario consta principalmente de bases de datos y, en menor medida,

de la estructura arbórea del disco. Desde los inicios de la maquetación, los centros de producción

han gestionado lo mejor que han podido para optimizar la organización de los datos: por lo general

se acostumbraban a las limitaciones porque no había otra opción (léase: no existía el concepto de

base de datos). Por eso muchos han aprendido a vivir copiando datos, y por lo que muchos han

optado por el procedimiento de asignar nombre a los archivos y carpetas, como si no hubiese otras

formas de mostrar las propiedades del archivo.

También hay otro efecto que salta a la vista: los pedidos de trabajo son temporales, sus datos

solamente existen mientras el pedido está activo (de días a semanas), más bien a corto plazo. Los

datos de un producto están pensados para un largo plazo: la carpeta que contiene todos los

recursos de producción es la “caja fuerte” del departamento de preimpresión. Los diseños de






plancha y los datos del RIP pueden ser datos a corto o largo plazo, BackStage acepta ambas

posibilidades.

BackStage siempre fue muy indulgente con la estructura de datos existente; ahora, con la

herramienta de productos, lo es aún más. Se recomienda a los clientes que utilicen esta

herramienta, que separen los datos que pertenecen a trabajos de los datos que pertenecen al

producto. Cuando un producto pertenece a un trabajo, la simple vinculación entre bases de datos se

encargará de realizar la conexión, por lo que finalmente se pueden separar las dos estructuras de

datos e incluso aplicarles distintos procedimientos de copia de seguridad y archivado. Lo lógico

sería archivar los datos de trabajos manteniendo los datos de productos.

Integración JDF/JMF

Un recurso de producción unitario se puede convertir en un producto BackStage de varias formas: • manualmente (a través de la tarea ‘Add to Products’, quizás junto con otros 200 recursos,

localizados con una herramienta de búsqueda inteligente) • o a través de JDF/JMF.

Los trabajos de BackStage hace años que se crean a través de JDF/JMF. Casi el 10% de los usuarios de BackStage han activado esta integración con su sistema MIS (un sistema personalizado o un producto MIS comercial). El siguiente paso lógico sería no sólo crear el trabajo de BackStage (con su carpeta de trabajo azul y los parámetros del pedido de trabajo como el nombre del cliente, la fecha de entrega, etc.) sino también recibir los nombres de los productos vinculados a dicho trabajo a través de JDF/JMF. Se trata de una pieza primordial de información de la definición del trabajo que hasta ahora no se “transmitía” de forma digital. Además de hacer referencia a un elemento existente en la base de datos de productos de BackStage, un comando JDF/JMF también puede crear un nuevo producto. BackStage lo creará en su base de datos de productos y mostrará una miniatura vacía. Posteriormente, el departamento de preimpresión añadirá el recurso correcto a dicho producto. EskoArtwork colabora con distintos fabricantes de sistemas MIS para permitir esta funcionalidad en sus exportaciones JDF/JMF.

La herramienta BackStage Products se encuentra en fase beta desde la versión 7.0 release 4

(publicada en agosto de 2008). La versión definitiva para los clientes será la v 7.0 release 5.




BackStage Viewer: una potente herramienta de visualización y comparación Imagen 1: BackStage Viewer se inicia desde el cliente BackStage Pilot (Mac/Windows)

Si BackStage Viewer puede abrir el archivo, la columna View mostrará un enlace para abrirlo.




Imagen 2: Aprovéchese de herramientas de ampliación ilimitada y medición precisa

El archivo original (izquierda) incluye solapado, el archivo de referencia (derecha) no. El solapado es de 0,3 mm. Imagen 3: Analice las separaciones en distintos modos de visualización




Imagen 4 y 5: Compare y analice las diferencias

La imagen muestra una típica diferencia después de que el archivo quedase listo para imprenta. En

este caso, el usuario esperará que haya diferencias, pero aquí comprobará las diferencias *no

deseadas*. Seguro que sabe que se desplazó parte del texto, que se añadió el código de barras y

que se aplicó solapado al archivo, pero ¿por qué es distinto el logotipo inferior? El atributo knock-

out accidental del logotipo es el error que el usuario agradecerá detectar aquí y no en la plancha o,

aún peor, en la máquina de impresión.

La imagen de arriba muestra las diferencias en modo resaltado; el usuario también puede optar por

ver “sólo diferencias” (abajo) o ver los archivos uno frente a otro.




Imagen 6 y 7: Comparación de una plancha RIPeada con un PDF unitario

La capacidad de BackStage de abrir numerosos formatos de preimpresión también quedará clara en el cliente Viewer. Uno de los aspectos más impresionantes del Viewer es su compatibilidad de ficheros.




BackStage Viewer puede abrir los siguientes formatos de archivo:

• Gráficos o Esko Normalized PDF (unitario), PDFPLA (diseño de plancha) o ArtPro o PDF o EPS/PS, DCS/EPS o AI - Adobe Illustrator (compatible con PDF) o Formatos antiguos de Esko GRS, PLA y EPF

• Datos de imagen o PSD – Adobe Photoshop o EPS o TIFF (< 600 ppi) o Antiguo Esko CT

• Datos de RIP o TIFF 1 bit > 600 ppi, LEN o Escala de grises o DCS 2.0 > 600 ppi

Y una vez abierto, el archivo se puede comparar con cualquier otro archivo abierto. Algunos ejemplos:

• Archivo de diseño AI inicial con el archivo de producción final (PDF o ArtPro) • Comparación de versiones o variantes de archivos de producción • Comparación de archivos montados y RIPeados con PDF/ArtPro unitarios o montados • Etc…

BackStage Viewer forma parte del módulo Power pack y se publicó en BackStage v 7.0 Release 4

DATENBLATT ZU ESKOARTWORK BACKSTAGE „PRODUCTS“ UND BACKSTAGE VIEWER

EG_pr585hide_BackStage-Factsheet

September 2008

1 / 15

EskoArtwork erweitert BackStage um Ansichts-, Vergleichs- und Datenverwaltungswerkzeuge1

BackStage Products: Optimiertes Auftrags- und Datenmanagement Abbildung 1: Konzept und logische Abbildung der realen Abläufe

BackStage hatte bereits eine Jobdatenbank, die mit der Auftragserfassung des MIS- bzw.

Verwaltungssystems übereinstimmt. In BackStage stellen diese (blau gekennzeichneten) Jobs

Aufträge dar, die für die Druckvorstufenproduktion aktiv sind. „Products“ sind die einzelnen

Druckobjekte, die zu einem Job gehören. Demzufolge ist das neue Tool „BackStage Products“ die

Datenbank zur Darstellung der einzelnen Dateibestandteile, die innerhalb dieser Jobs in Auftrag

gegeben werden können.

1 Hinweis: Alle abgebildeten Screenshots stammen aus dem BackStage Pilot, der Benutzeroberfläche des BackStage-Clients, die auf Macintosh- und auf Windows-Plattformen zur Verfügung steht.



September 2008

2 / 15

Beispiel zur Veranschaulichung des Konzepts: In der Datenbank „BackStage Jobs“ werden z.B. 77

zu erledigende aktive Aufträge angezeigt. In der Datenbank „BackStage Products“ sind 20.000

Einzeldateien z.B. Bilder, Texte, Logos usw. für die Produktion gespeichert. Diese

Produktionsdateien wurden zu den „BackStage Produkts“ eingetragen, weil sie bei diesen 77

aktuellen Aufträgen oder später bei Folgeaufträgen verwendet werden.

Nahezu alle Mitarbeiter in der Druckvorstufe erhalten immer noch einen Ausdruck für die zu

bearbeitenden Aufträge. Dieser Ausdruck enthält genaue Angaben darüber, was mit welchen

Dateien zu machen ist. Diese Informationen lassen sich jetzt besser als zuvor in die Anwendung

übertragen, mit der sie tagtäglich arbeiten. Denn durch das Tool „Products“ gelangen sie einen

weiteren Schritt näher zur volldigitalen Kommunikation über die Jobverarbeitung, was weitaus

produktiver ist, als die bislang übliche papier- und dateibasierte Produktion.

Abbildung 2: Die Galerie BackStage Products

In der Galerie BackStage Products werden alle Produkte angezeigt, die in der Datenbank

gespeichert sind. Die Oberfläche mit den Miniaturansichten lässt sich als Listenansicht darstellen,

die nähere Einzelheiten über die Produkteigenschaften enthält. Die Farbleiste zeigt den Status an,

der sich in der Regel auf den Genehmigungs- oder einen anderen benutzerdefinierten Status

bezieht. Diese Abbildung zeigt eine gefilterte Ansicht aller Produkte des Kunden „Funky“.



September 2008

3 / 15

Auch benutzerdefinierte Filter sind möglich, z. B. alle genehmigten Aufkleber des Kunden

„Funky“ für die Vorderseite. Eine Datenbank ist intelligenter und schneller als das zeitaufwändige

Suchen und Umbenennen von Dateien, was heute gang und gäbe ist. BackStage-Operator waren

bereits an die Auftragsdatenbank gewöhnt. Mit dem Tool Products verfügen sie jetzt über eine

wesentliche Erweiterung ihrer Möglichkeiten. Sie haben sich daran gewöhnt, den anstehenden Job

schnell zu finden, jetzt werden sie es schätzen, dass sie die zu verwendenden Dateibestandteile

schnell finden können.

Für den Benutzer von BackStage, angenommen es handelt sich hier z.B. um eine Druckerei, stellt

ein BackStage Product eine Produktionsdatei dar. Die Firma kann einen Auftrag für dieses Produkt

erhalten. Beispiel: Eine Druckerei für Bierflaschenetiketten erhält einen Auftrag für den (Nach-)

Druck von 24.000 Etiketten für die Vorderseite, 24.000 Etiketten für den Flaschenhals, 12.000

Etiketten für die Rückseite in Französisch und 12.000 Etiketten für die Rückseite in Spanisch. Für

den Weiterverarbeiter sind dies also 4 Aufträge/Produkte bzw. 4 separate Etiketten. Der Endkunde

des Weiterverarbeiters, d. h. der Markeninhaber, nennt die volle Flasche mit den 3 Etiketten sein

„Produkt“. In Verwaltungs- und Produktionsanwendungen, die bei Weiterverarbeitern im Einsatz sind,

werden auch andere Synonyme für unseren Begriff „BackStage Products“ verwendet, nämlich

Objekte, Artikel oder SKU (Stock Keeping Unit, d. h. Artikelnummer).

Abbildung 3: BackStage Products sind mit BackStage Jobs verknüpft

Die Abbildung zeigt, wie ein Operator 4 Fruchtsaft-Etiketten mit dem BackStage Job

„66789“ verknüpft hat. In seinem Arbeitsblatt hat er gelesen, dass es bei diesem Auftrag um diese 4

Produkte geht. Danach liest er die weiteren Anweisungen für die Ausgabe. Ihm wird angeboten,

seine bevorzugten Tasks zu starten. Und er sieht die Tasks, die im Zusammenhang mit diesem Job

bereits ausgeführt wurden.



September 2008

4 / 15

An dieser Stelle kommt der Hauptvorteil zum Tragen: Wenn der Operator diese 4 Produkte in

diesem Auftrag miteinander verknüpft, muss er die Daten nicht kopieren; er muss nur eine

Verknüpfung zwischen den 2 Datenbanken herstellen. Anstelle von Kopien kann er nunmehr mit

diesen schnellen Verknüpfungen arbeiten. Visuell gehören die Daten zum Auftrag; physische Kopien

sind jedoch nicht mehr notwendig. Nutzlose Kopien belegen mehr Festplattenspeicher und

verursachen zusätzliche Verwirrung dahingehend, welche Version tatsächlich die zuletzt

genehmigte Endversion ist und welche Version „tatsächlich“ in Job XYZ verwendet wurde usw.

Bei Weiterverarbeitern sind die folgenden Auftragstypen an der Tagesordnung:

Bei der einfachsten Art dieses Jobs handelt es sich um den Nachdruck („Re-Run“) der 4

vorhandenen Etiketten. In diesem Fall muss der Operator nur eine Nutzenkopie (Step &

Repeat) der Etiketten erstellen, ohne den Genehmigungszyklus durchlaufen zu müssen,

und leitet das Plattenlayout an den RIP weiter. Dieser Auftragstyp wird häufig „Re-Run No

Change“ (RRNC) genannt, d. h. erneute Ausführung ohne Änderungen.

Bei einem anderen Auftragstyp müssten kleinere Änderungen an einem oder mehreren

dieser Produkte vorgenommen werden. Dabei kann eine Änderung so geringfügig sein,

dass beschlossen wird, die neue Datei nicht als ein anderes Produkt anzusehen. Daher



September 2008

5 / 15

darf der Operator die Produktionsdatei überschreiben. Zum Beispiel: Verschieben Sie den

Namen des Safts um 1 mm nach links. Durch diesen „Re-Run With Change“ (RRWC, d. h.

erneute Ausführung mit Änderungen) wird u. U. auch ein neuer Genehmigungszyklus

erforderlich.

Wenn vereinbart wird, dass die Änderung nicht zu einem neuen Design führt (also nicht

als separate Version vom vorherigen Design anzusehen ist), dann wird ein neues Produkt

erstellt. Beispiel: ein aktualisiertes Logo oder Bild oder eine Textänderung. Der Name (in

der Regel eine Nummer) dieses neuen Produkts (genau genommen eine neue Variante)

kann vom MIS oder sogar in der Druckvorstufe festgelegt werden. Wenn das alte Design

nicht mehr wieder in Auftrag gegeben werden darf, kann dies ein Grund dafür sein, dieses

Design aus der Produktdatenbank zu entfernen (man könnte es aber auch darin lassen

und ihm den benutzerdefinierten Status „veraltet“ zuweisen).

In einem anderen Szenario geht es um einen Job mit 1 oder mehreren *neuen* Produkten

oder um eine Mischung der o. g. Auftragstypen. In diesem Fall erstellt der Operator zuerst

eine druckreife Version des Entwurfs (Korrektur der Farbauszüge, Hinzufügen eines

Barcodes, Trapping, Korrektur des Beschnittformats/der Stanzform usw.) und bestimmt,

dass diese Produktionsdatei ein echtes BackStage-Produkt wird. Dieser Arbeitsschritt

kann manuell erfolgen oder Bestandteil der Workflow-Automatisierung sein.

Die Bearbeitungsanwendungen PackEdge (Nutzenbearbeitung) und Plato (Plattenlayout) sind in

diesem Produkt-Konzept bereits integriert: Der Operator wird zu den fraglichen Produktdateien in

dem Job geleitet, an dem er gerade arbeitet. Diese Integration kann auch in ArtPro erfolgen. In der

Anwendung Plato, in der Sie eine Nutzenkopie von den Produkten im Job erstellen möchten, gibt

Ihnen das Menü die Möglichkeit, bestimmte oder alle Produkte des Jobs zu laden. Auch in diesem

Fall muss der für das Plattenlayout verantwortliche Operator nicht nach der richtigen Datei suchen.

Abbildung 4: Produktbestandteile („Parts“)

Ein Produkt kann aus mehreren Teilen bestehen. Ein typisches Beispiel dafür sind Aufträge mit

Schön- und Widerdruck. Diese 2 Seiten sind u. U. mit 2 unterschiedlichen Produktions-PDF-Dateien

verknüpft. Doch nach mehreren Druckläufen oder sogar nach der Weiterverarbeitung könnten sie zu

einem Produkt beim Weiterverarbeiter werden. Bei einem anderen Beispiel könnte es sich um ein

Produkt handeln, das aus mehreren Teilen besteht und ein schwarzes Etikett mit aufgeklebter

Broschüre ist.



September 2008

6 / 15



September 2008

7 / 15

Abbildung 5: Eigenschaften eines Produkts

Dieses Produkt hat 2 Bestandteile. Hier werden die allgemeinen Produkteigenschaften angezeigt

(„Product Setup“), d. h. natürlich der Name und die ID, der Kunde und der vom Kunden festgelegte

Produktname, benutzerdefinierte Felder für die Kategorisierung und Filterung, eine Freitext-

Beschreibung und der Status (sofern dieser für alle Bestandteile ähnlich ist).

Abbildungen 6 und 7: Eigenschaften eines Produktbestandteils

Diese Abbildung zeigt die Eigenschaften

des ersten Produktbestandteils. Die

Registerkarte „Status“ ist ausgewählt.

Der Status besagt, dass dieser

Bestandteil genehmigt ist. Ein

Produktbestandteil kann manuell oder

automatisch genehmigt werden, sofern

die Genehmigung im WebCenter

angefordert wurde.



September 2008

8 / 15

Diese Abbildung zeigt die Eigenschaften

des zweiten Produktbestandteils. Die

Registerkarte „Barcode“ ist ausgewählt.

Der Barcode lässt sich durch eine

separate Task im Hintergrund prüfen

und erzwingen.

Abbildung 8: Auswirkung auf die Datenstruktur

Aufgrund der Tatsache, dass Sie die Nutzendaten nicht mehr in einen Ordner kopieren müssen, der

den Auftrag darstellt, haben Sie die Möglichkeit, den Datenserver auf andere Weise zu organisieren.

Jetzt besteht die Benutzeroberfläche im Wesentlichen aus den Datenbanken und weniger aus einer

Baumstruktur. Schon in den Anfangsjahren im DTP hat man immer versucht, die Datenverwaltung

zu optimieren. Dabei stieß man häufig an Grenzen, weil es einfach keine Möglichkeiten dazu gab

(d. h. kein Datenbank-Konzept). Man hatte keine andere Wahl und musste Daten kopieren und

begnügte sich Dateien und Ordnern, weil es keine anderen Möglichkeiten gab und die

Eigenschaften einer Datei nicht angezeigt werden konnten.



September 2008

9 / 15

Ein anderer Effekt wird auch klar: Jobbezogene Aufträge sind temporärer Natur; ihre Daten haben

nur so lange Bestand, wie der Auftrag aktiv ist (Tage bis Wochen), sind also kurzfristig.

Produktdaten sind langfristige Daten. Der Ordner, in dem alle diese Produktionsdateien gespeichert

sind, ist der „Tresor“ der Druckvorstufenabteilung. Bei Plattenlayouts und RIP-Daten kann es sich

um kurzfristige oder um langfristige Daten handeln; von BackStage werden beide Optionen

unterstützt.

BackStage war immer äußerst nachsichtig mit der vorhandenen Datenstruktur und ist jetzt mit dem

Tool Productsׂ sogar noch nachsichtiger. Kunden, die mit diesem Tool arbeiten, sollten die Daten,

die zu Jobs gehören, nach Möglichkeit von den Daten trennen, die zum Produkt gehören. Wenn ein

Produkt zu einem Job gehört, wird jetzt durch die einfache Verknüpfung zwischen den Datenbanken

eine Verbindung hergestellt. Dadurch können Sie diese Datenbäume jetzt voneinander trennen und

ihnen sogar ein unterschiedliches Sicherungs- und Archivierungsverfahren zuweisen. Es wäre

logisch, die Jobdaten zu archivieren, die Produktdaten jedoch online zu behalten.



September 2008

10 / 15

JDF/JMF-Integration

Eine Nutzendatei lässt sich auf verschiedene Weise zu einem BackStage Product machen: • manuell (über die Task „Add to Products“, u. U. zusammen mit 200 anderen Dateien, die

sich mit einem intelligenten Suchwerkzeug finden lassen) • oder mittels JDF/JMF.

Seit vielen Jahren werden BackStage-Jobs bereits mittels JDF/JMF erstellt. Fast zehn Prozent aller

BackStage-Benutzer haben diese Integration in ihr MIS (ein benutzerdefiniertes System oder ein

handelsübliches MIS) bereits aktiviert.

Als Nächstes liegt es auf der Hand, nicht nur den BackStage-Job erstellen zu lassen (mit seinem

blau dargestellten Jobordner und den Auftragsparametern wie Kundenname, Fälligkeitsdatum usw.),

sondern mittels JDF/JMF auch die Namen der Produkte zu erhalten, die beim fraglichen Job

involviert sind. Dies sind wichtige Informationen in der Jobdefinition, die bislang nicht digital

„weitergeleitet“ wurden. Ein JDF/JMF-Befehl kann sich nicht nur auf ein vorhandenes Objekt in der

Datenbank BackStage Products beziehen, sondern kann sogar ein neues Produkt erstellen.

BackStage erstellt das Produkt in seiner Produktdatenbank und zeigt eine leere Miniaturansicht an.

In der Druckvorstufe wird dann später die richtige Datei mit diesem Produkt verknüpft.

EskoArtwork arbeitet mit mehreren MIS-Anbietern zusammen, um diese Option in ihrem JDF/JMF-Export zu ermöglichen.

Das Tool BackStage Products befindet sich seit Version 7.0 Release 4 (die im August 2008

eingeführt wurde) in der Betaphase und soll in Version 7.0 Release 5 für Kunden freigegeben

werden.



September 2008

11 / 15

BackStage Viewer: ein erstaunliches Ansichts- und Vergleichswerkzeug Abbildung 1: Der BackStage Viewer wird in einem Back Stage Pilot-Client (Macintosh/Windows) gestartet.

Wenn der BackStage Viewer die Datei öffnen kann, bietet die Spalte „Views“ einen Hyperlink zum Öffnen der Datei.



September 2008

12 / 15

Abbildung 2: Vorteile der unbegrenzten Möglichkeiten der Vergrößerungs- und Messwerkzeuge

Die Originaldatei (links) enthält Überfüllungen, die Referenzdatei (rechts) nicht. Die Überfüllung ist 0,3 mm breit. Abbildung 3: Analyse der Farbauszüge in mehreren Ansichtsmodi



September 2008

13 / 15

Abbildungen 4 und 5: Vergleich und Analyse der Unterschiede

Die Abbildung zeigt einen typischen Unterschied, nachdem eine Datei druckreif gemacht wurde. Bei

diesem Verwendungsbeispiel erwartet der Benutzer Unterschiede; er sucht jedoch nach

„unerwünschten“ Unterschieden. Natürlich weiß er, dass bestimmte Textteile verschoben wurden,

dass der Barcode hinzugefügt wurde und dass die Datei überfüllt wurde. Doch warum sieht das

Logo rechts unten anders aus? Der Benutzer wird froh sein, dass er das versehentliche Aussparen

des Logos hier und nicht erst auf der Platte oder, was noch schlimmer wäre, beim Drucken

festgestellt hat.

Die Abbildung oben zeigt die Unterschiede im Hochlicht-Modus. Der Benutzer hat auch die Option,

sich nur die Unterschiede (unten) oder sich die Dateien nebeneinander anzeigen zu lassen.



September 2008

14 / 15

Abbildungen 6 und 7: Vergleichen einer gerippten Platte mit einer PDF-Nutzendatei

Die Tatsache, dass BackStage so viele Druckvorstufenformate lesen kann, wird auch in seinem Client „Viewer“ offenkundig. Dieser Viewer besticht durch die Vielzahl der unterstützten Dateiformate.



September 2008

15 / 15

Die folgenden Dateiformate lassen sich im BackStage Viewer öffnen:

• Grafiken o Esko Normalized PDF (Nutzen), PDFPLA (Plattenlayout) o ArtPro o PDF o EPS/PS, DCS/EPS o AI - Adobe Illustrator (sofern PDF-kompatibel) o ältere Esko-Dateiformate wie GRS, PLA und EPF

• Bilddaten o PSD – Adobe Photoshop o EPS o TIFF (< 600 ppi) o älteres Esko-Dateiformat CT

• RIP-Daten o 1-Bit-TIFF > 600 ppi, LEN o Graustufen o DCS 2.0 > 600 ppi

Nach dem Öffnen lässt sich jede Datei mit einer anderen geöffneten Datei vergleichen. Beispiele:

• eine ursprüngliche AI-Grafikdatei mit der endgültigen Produktionsdatei (PDF oder ArtPro) • Vergleich verschiedener Versionen einer Produktionsdatei • Vergleich einer gerippten Nutzendatei mit einer PDF/ArtPro-Nutzendatei • usw.

Der BackStage Viewer ist ein Bestandteil des Moduls Power Pack und wurde in BackStage Version 7.0 Release eingeführt.

FICHE INFO ESKOARTWORK BACKSTAGE « PRODUCTS » et BACKSTAGE VIEWER

EskoArtwork enrichit BackStage d’outils de visualisation, de comparaison et de gestion des données1

BackStage Products : gestion optimisée des jobs et des données Image 1 : concept et logique métier

BackStage possède une base de données de commandes ou « Jobs », synchronisée avec la base

de saisie des commandes du système Admin. Dans BackStage, ces Jobs (en bleu) représentent les

Ordres de travail actifs en production prépresse. Les Produits sont des objets imprimables utilisés

dans le cadre d'un travail particulier. Ainsi, le nouvel outil BackStage « Products » constitue la base

de données des Produits pouvant être utilisés pour la réalisation des commandes.

1 Remarque : toutes les captures d’écran présentées sont extraites de BackStage Pilot, l’interface client de BackStage, disponible à la fois pour Macintosh et Windows. EG_pr585hifr_BackStage-Factsheet

Septembre 2008 1 / 16


EG_pr585hifr_BackStage-Factsheet


Un exemple pour illustrer le concept : la base de données de Jobs de BackStage affiche 77 jobs

actifs à produire ; la base de données de Produits de BackStage contient 20 000 PDF de maquettes

de production (simple pose). Les éléments composant ce fonds numérique ont été constitués en

Produits BackStage car ils sont susceptibles d’être utilisés dans le cadre de ces 77 Ordres de travail

ou pour des commandes futures.

La quasi-totalité des opérateurs de production prépresse reçoivent encore un ordre d’exécution

imprimé : cette feuille de papier précise ce qu’il y a lieu de faire et avec quels Produits. Cette

information est désormais plus que jamais transposable dans l’application qu’ils utilisent

quotidiennement. L’outil Products les fait encore progresser d’une étape vers une communication

entièrement numérique sur le traitement des jobs. Une approche bien plus productive que les

solutions actuelles, basées sur les bons de travail et les fichiers.

Image 2 : galerie des Produits BackStage

La galerie de Produits de BackStage affiche tous les Produits présents dans la base de données. La

présentation en icônes peut faire place à un affichage sous forme de liste, qui fournit de plus amples

détails sur les propriétés du Produit. La barre de couleur est indicative d’un état. Celui-ci a trait

généralement à l’approbation du Produit ou à un autre état personnalisé. La présente image affiche




une vue filtrée de tous les Produits relatifs au client « Funky Foods ». Il est en effet possible de

définir des filtres sur mesure, pour n’afficher, par exemple, que toutes les étiquettes adhésives

approuvées par le client « Funky Foods ». Une base de données offre une approche plus

intelligente et plus rapide que la recherche approfondie sur les noms des fichiers utilisés jusque-là.

Les opérateurs BackStage étaient déjà familiers de la base de données des Ordres de travail. L’outil

Products facilite encore davantage le processus. De même qu’ils ont pris l’habitude d’avoir le bon

Job directement à portée de main, ils apprécieront de trouver facilement les fichiers de Produits à

utiliser.

Pour l’utilisateur de BackStage, généralement un transformateur, un Produit BackStage représente

un produit fini. Le transformateur peut recevoir une commande pour ce Produit. Par exemple : une

demande de (ré)impression de 24 000 étiquettes de bouteille de bière, plus 24 000 collerettes et

12 000 contre-étiquettes en français et 12 000 en espagnol. Pour lui, il s’agit de 4 Produits, de 4

étiquettes uniques. Pour son client final (la marque), le « produit » est la bouteille remplie, ornée des

3 étiquettes. Le système d’administration et les applications de production des transformateurs

peuvent employer d’autres synonymes pour désigner ce que nous appelons des Produits

BackStage : références, articles, unités (de gestion) de stock (SKU), etc.

Image 3 : liaison des Produits BackStage aux Jobs BackStage

L’image montre comment un opérateur a lié 4 Produits d’étiquette de jus de fruit dans le Job

BackStage « 66789 ». Il a lu sur son bon d’exécution que cette commande concerne 4 Produits ; il

va à présent pouvoir consulter la suite des instructions. Le logiciel lui propose la liste des tâches

habituelles et l’informe sur celles qui ont déjà été effectuées dans le contexte de ce Job.

Et c’est là qu’intervient le principal avantage : lorsque l’opérateur « relie » ces 4 Produits dans cet

Ordre de travail, il ne copie pas les données, mais établit simplement des liens entre les 2 bases de

données. Il travaille avec des raccourcis et non plus sur des copies. Si, visuellement, les données

appartiennent à l'Ordre de travail, des copies physiques ne sont plus nécessaires. Toutes ces

copies inutiles ne font qu'engendrer un besoin supplémentaire d’espace de stockage. En outre, nul

ne sait vraiment quelle est la dernière version finale acceptée, laquelle a effectivement été utilisée

dans le Job XYZ, etc.




Voici les types d’ordre de travail que l’on rencontre généralement chez un transformateur :

La forme la plus simple d’un Job serait une réimpression de 4 étiquettes existantes.

L’opérateur n’a rien d’autre à faire que les répéter sur la forme imprimante (sans cycle

d’approbation) et d’envoyer celle-ci au RIP. Ce type de commande constitue un retirage à

l’identique (Re-Run No Change).

Une commande peut aussi nécessiter de modifier légèrement un ou plusieurs produits

existants. Le changement peut être si infime qu’il n’est peut-être pas nécessaire de

considérer le nouveau fichier comme constituant un Produit à part. L’opérateur peut alors

être autorisé à remplacer le précédent fichier de production. Par exemple, dans le cas d’un

simple décalage du nom du jus de 1 mm vers la gauche. Ce retirage modifié (Re-Run With

Change) peut être conditionné à un nouveau cycle d’approbation.

S’il est convenu que la modification donne effectivement lieu à une nouvelle création

(distincte de la précédente), un nouveau Produit sera créé. Par exemple, l'actualisation

d’un logo ou un changement d’illustration ou de texte. Le nom (généralement un numéro)

de ce nouveau Produit (en fait une nouvelle variante) peut être généré par le MIS ou

même choisi par le prépresse. S’il y a lieu de penser que l’ancienne création ne fera plus




jamais l’objet d’une recommande, elle peut être supprimée de la base de données des

Produits (il est également possible de la conserver en lui donnant un statut « obsolète »).

Dans un autre cas de figure, le Job concerne un ou plusieurs Produits « nouveaux » ou un

mix des types de commandes précédents. Dans ce scénario, l’opérateur prépare d’abord

la création jusqu'au prêt-à-imprimer (génération des séparations, ajout d’un code à barres,

recouvrement, rognage, forme de découpe, etc.), après quoi il promeut ce fichier au statut

de Produit BackStage. Cette opération peut être manuelle ou s’intégrer à un flux de tâches

automatisé.

Les applications d'édition PackEdge (maquette simple pose) et Plato (plaque composée) sont déjà

intégrées dans le concept de BackStage Products : l’opérateur est guidé vers les fichiers de produits

pertinents pour le Job dans lequel il travaille. Cette intégration sera également réalisée dans ArtPro.

Dans Plato, qui permet éventuellement d’effectuer une copie-répétition des Produits pour le Job, le

menu de grille offre la possibilité de charger certains ou tous les Produits du Job. De nouveau,

l’opérateur chargé de composer la plaque imposée n’a plus à chercher et localiser les éléments

nécessaires.




Image 4 : « Parties » de Produits

Un même Produit peut se composer de nombreuses « Parties ». Par exemple, des étiquettes

imprimées recto verso. Ces deux 2 faces peuvent se rapporter à 2 PDF de production différents,

mais finir, au fil des étapes d’impression, voire après la finition, par constituer un seul Produit dans

le stock du transformateur. Autre exemple d’un Produit en plusieurs « Parties » : une contre-

étiquette comportant un livret collé.




Image 5 : propriétés d’un Produit

Ce Produit comporte 2 Parties. Ses propriétés générales sont présentées ici (« Product

Properties »). On y voit bien sûr le nom et l’identifiant du produit, le nom du client et la référence

donnée au produit par ce client, des champs personnalisables pour la catégorisation et le filtrage,

une description libre et une indication d’état (s’il est identique pour toutes les Parties).




Images 6 et 7 : propriétés des Parties d’un Produit

Cette image affiche les propriétés de la première Partie du Produit. L’onglet « Status » est

sélectionné. Vous pouvez y voir, selon son état, que cette partie a été approuvée. Une Partie de

Produit peut être approuvée manuellement ou automatiquement si l’approbation a été demandée

sur WebCenter.




Cette image affiche les propriétés de la deuxième Partie du Produit. L’onglet « Barcode » est

sélectionné. Le code à barres peut être vérifié et forcé en arrière-plan par une tâche dédiée.


Image 8 : effet sur la structure des données

Le fait que vous ne deviez plus copier les données de la maquette dans un dossier représentant

l’Ordre de travail ouvre la possibilité d’organiser le serveur de données de manière différente.

L’interface de l’opérateur s’articule désormais autour des bases de données et s’appuie dès lors

moins sur l’arborescence du disque. Depuis les débuts de la microédition, les sites de production se

sont efforcés de gérer l’organisation des données du mieux possible. Souvent, ils se sont

accommodés de leurs limitations, faute de pouvoir faire autrement (absence de concept de base de

données). De ce fait, beaucoup ont pris leur parti de copier les données, inventant des procédures

fondées sur les noms de fichiers et de dossiers, seules manières de conférer une certaine visibilité

aux propriétés de leurs contenus.

Autre conséquence manifeste, les ordres de travail sont temporaires. Leurs données subsistent

aussi longtemps que la commande est active (de quelques jours à quelques semaines), ce qui reste

relativement du court terme. Les données des Produits durent sur le long terme : le dossier avec

tous ces actifs de production est la « chambre au trésor » du service prépresse. Les formes

imposées et les données du RIP peuvent être à court ou à long terme. BackStage autorise les deux.






BackStage a toujours été très respectueux de la structure de données existante ; avec l’outil

Products, il l’est plus encore. Il est conseillé aux clients qui utilisent l’outil Products de distinguer les

données des Jobs de celles qui appartiennent aux Produits. À présent, lorsqu’un Produit est attribué

à un Job, la simple liaison entre les deux bases de données suffit à établir la connexion. Vous

pouvez donc scinder ces deux arborescences et, éventuellement, leur appliquer des procédures de

sauvegarde et d’archivage propres. La logique voudrait que les données de Jobs soient archivées

mais que les données de Produits restent en ligne.

Intégration JDF/JMF

Il existe deux manières d'élever un élément de production numérique une pose au statut de Produit BackStage :

• manuellement (via la tâche « Add to Products » (Ajouter aux Produits), éventuellement avec 200 autres éléments d’actifs, localisés à l’aide d’un outil de recherche intelligent) ;

• via JDF/JMF. Les Jobs BackStage sont créés par JDF/JMF depuis des années. Près de 10 % des utilisateurs de BackStage ont déjà rendu cette intégration possible dans leur MIS (qu’il s’agisse d’un système sur mesure ou d’un MIS disponible dans le commerce). L’étape suivante consiste non seulement à faire créer le Job BackStage (avec son dossier de production bleu et ses paramètres d’exécution, tels que le nom du client, la date de livraison prévue, etc.), mais aussi à recevoir les noms des Produits impliqués dans ce Job via JDF/JMF. Cet élément d’information important dans la définition du Job n’était pas transmis numériquement jusqu’ici. Outre qu’elle est capable de référer à un élément existant de la base des données des Produits BackStage, une commande JDF/JMF peut aussi créer un Nouveau produit. BackStage le crée dans sa base de données de Produits et en affiche une miniature vide. Le prépresse s’occupera par la suite d’associer l’élément d’actif concerné à ce Produit. EskoArtwork travaille actuellement avec plusieurs fournisseurs de MIS à activer cette possibilité dans leurs exportations JDF/JMF.

L’outil BackStage Products est disponible en version bêta depuis la version 7.0 Release 4 (sortie en

août 2008). Il sera commercialisé dans la version 7.0 Release 5.




BackStage Viewer : formidable outil de visualisation et de comparaison Image 1 : BackStage Viewer se lance à partir du client BackStage Pilot (Mac/Windows)

Si BackStage Viewer est en mesure d’ouvrir le fichier, la colonne View propose un hyperlien vers celui-ci.




Image 2 : outil de zoom et de mesures détaillées aux possibilités illimitées

Le fichier d’origine (à gauche) contient des recouvrements, contrairement au fichier de référence (à droite). Épaisseur de recouvrement : 0,3 mm. Image 3 : analyse des séparations en plusieurs modes de visualisation




Images 4 et 5 : comparaison et analyse des différences

L’illustration montre une différence caractéristique après la préparation d’un fichier à l’impression.

L’utilisateur s’attend à des différences, mais, en l’occurrence, il va vérifier la présence de différences

« indésirables ». Il sait pertinemment que du texte a été déplacé, qu’un code à barres à été ajouté et

que les recouvrements ont été générés, mais quel est le problème avec le logo en bas à droite ?

L’attribut de surimpression du logo est l’erreur que l’utilisateur sera heureux d’avoir détectée à ce

stade plutôt que sur la plaque, voire pire, sur la presse.

L’image ci-dessus montre les différences mises en évidence ; l’utilisateur peut choisir de

voir «uniquement les différences » (ci-dessous) ou d'afficher les fichiers côte à côte.




Images 6 et 7 : comparaison d’une plaque rippée avec la maquette PDF

BackStage est capable de lire une multitude de formats prépresse ; une polyvalence qui transparaît également dans son client Viewer. L’un des aspects les plus étonnants de ce Viewer est en effet sa prise en charge des formats de fichier.




Les fichiers de formats suivants peuvent être ouverts dans BackStage Viewer :

• Fichiers graphiques o PDF normalisé Esko (simple pose), PDFPLA (composition) o ArtPro o PDF o EPS/PS, DCS/EPS o AI - Adobe Illustrator (si compatible PDF) o Formats Esko antérieurs : GRS, PLA et EPF

• Données d’image o PSD – Adobe Photoshop o EPS o TIFF (< 600 ppi) o CT Esko antérieur

• Données rippées o TIFF 1 bit > 600 ppi , LEN o Gamme de gris o DCS 2.0 > 600 ppi

Une fois ouvert, n’importe quel fichier peut être comparé à n’importe quel autre fichier ouvert. Quelques exemples :

• Fichier de création AI initial avec fichier de production final (PDF ou ArtPro) • Comparaison de versions ou de variantes de fichiers de production • Comparaison de sorties répétées et rippées par rapport au fichier PDF/ArtPro une pose ou

répété • Etc.

BackStage Viewer fait partie du module pack Power et a été lancé pour la première fois dans BackStage version 7.0 Release 4

ALLEGATO TECNICO SU ESKOARTWORK BACKSTAGE ‘PRODUCTS’ e BACKSTAGE VIEWER

EG_pr585hiit_BackStage-Factsheet

Settembre 2008

1 / 16

EskoArtwork estende BackStage con nuovi strumenti di visualizzazione, confronto e gestione dati 1

BackStage Products: Gestione ottimizzata dei lavori e dati Immagine 1: I concetti di base e la logica di gestione

BackStage offriva già un database dei lavori, mantenuto dall'amministratore di sistema, che

consentiva la ricerca degli ordini di lavoro eseguiti. In BackStage, questi lavori, rappresentati in

colore blu, corrispondevano ad ordini pronti per la prestampa. I Prodotti rappresentano invece

singoli oggetti od elementi di un progetto di stampa, che appartengono ad un lavoro. Il nuovo

strumento BackStage Products, quindi, è un database di Prodotti che possono essere ordinati per

essere raggruppati all'interno di nuovi ordini di lavoro.

1 Nota: Tutte le videate presentate provengono da BackStage Pilot, l’interfaccia cliente di BackStage disponibile sia per Mac che per Windows.



Settembre 2008

2 / 16

Il seguente esempio spiega meglio questo concetto: Il database dei lavori BackStage mostra 77

lavori attivi pronti per essere eseguiti. Il database di BackStage Products può memorizzare fino a

20.000 PDF finali utilizzabili per la produzione. Questi elementi della produzione sono stati utilizzati

per creare dei Prodotti BackStage, nell'ottica di riutilizzarli all'interno degli attuali 77 lavori in attesa,

o per qualsiasi altro futuro ordine.

Quasi tutti gli operatori di prestampa ancora oggi ricevono una stampata cartacea con una lista delle

operazioni da effettuare: il foglio spiega come operare. Questa informazione oggi può essere

eseguita ancora più facilmente attraverso le applicazioni che si utilizzano quotidianamente. Lo

strumento Products consente di compiere un ulteriore passo verso la comunicazione

completamente digitale sulle modalità di preparazione di un lavoro; una metodologia molto più

produttiva rispetto all'uso del foglio di carta accompagnato dai file, come si fa oggi.

Immagine 2: La galleria di BackStage Products

La galleria di BackStage Products mostra tutti i Prodotti che sono stati definiti nel database.

L'interfaccia mette a disposizione delle piccole visualizzazioni di anteprima degli elementi, e può

essere attivata una visualizzazione a lista, che offre maggiori dettagli sulle caratteristiche di ciascun

Prodotto. La barra colore indica uno stato, tipicamente legato ad una approvazione o ad un'altra

situazione personalizzabile. Questa immagine mostra una vista filtrata di tutti i prodotti realizzati per



Settembre 2008

3 / 16

il cliente 'Funky'. È possibile definire dei filtri personalizzati, ad esempio tutte le etichette con adesivo

frontale approvate per il cliente 'Funky'. Un database è più intelligente e veloce rispetto agli

strumenti di ricerca e di denominazione file che si usano normalmente oggi. Gli operatori di

BackStage sono già abituati ad usare un database per gestire gli ordini di lavoro, e questo

strumento di gestione dei Prodotti costituisce un netto miglioramento rispetto al modo con cui

lavoravano prima. Per gli utilizzatori di BackStage è facile trovare il lavoro da aprire, ed ora sarà

facile anche trovare i file di Prodotto da usare.

Per l'utente BackStage, il più delle volte un trasformatore, un Prodotto BackStage rappresenta un

Prodotto finito. Il trasformatore può ricevere un ordine per questo Prodotto. Esempio: uno

stampatore di etichette di bottiglie di birra può ricevere un ordine di (ri)stampa di 24.000 etichette

frontali, 24.000 etichette collo, 12.000 etichette retro in francese e 12.000 etichette retro in spagnolo.

Per il trasformatore questi sono 4 Prodotti, cioè 4 etichette distinte. Per il cliente, invece, il 'prodotto'

è la bottiglia, piena, e dotata delle sue 3 etichette coordinate. Le applicazioni gestionali e di controllo

di produzione utilizzate dai trasformatori utilizzano altri sinonimi, per quelli che noi chiamiamo

Prodotti in BackStage: elemento, item, articolo, unità, pezzo, SKU (Stock Keeping Unit).

Immagine 3: I Prodotti BackStage sono collegati ai Lavori BackStage

L'immagine mostra come un operatore abbia collegato 4 diversi prodotti di etichette per succhi di

frutta, in un unico lavoro BackStage con il nome '66789'. Il suo foglio di istruzioni operative spiegava

che questo ordine contiene i 4 Prodotti; successivamente dovrà seguire le istruzioni che spiegano

come impostare l'output. Il sistema mostra le attività preimpostate disponibili per il lancio del lavoro

in output, ed elenca le operazioni già effettuate precedentemente nel contesto di quel lavoro.



Settembre 2008

4 / 16

Proprio qui sta il principale vantaggio di questo modo di lavorare: Quando l'operatore 'collega' questi

ti

Ecco alcuni esempi classici di ordini di lavoro per i trasformatori:

La forma più semplice di questo lavoro consiste nella ristampa di 4 etichette già esistenti.

L'operatore deve quindi, senza alcun ciclo di approvazione, effettuare la ripetizione degli

elementi e mandare il foglio macchina per la lastra in elaborazione al RIP. Molti chiamano

questo tipo di lavorazione "Ristampa Senza Cambiamenti" (RRNC).

Un diverso tipo di ordine di lavoro è quello in cui vengono richieste delle piccole modifiche

ad uno o più dei prodotti. La modifica può essere così minima che si decide di non creare

un nuovo file come nuovo prodotto: l'operatore decide semplicemente di sovrascrivere la

precedente versione del file di produzione. Ad esempio: Spostare il nome del succo di

4 Prodotti nell'ordine di lavoro, non effettua una copia di questi dati, ma crea dei semplici riferimen

tra i 2 database. Invece di fare delle copie, ora può lavorare accedendo velocemente alle

informazioni. I dati appartengono visivamente all'ordine di lavoro, ma non vi è più la necessità di

creare delle copie fisiche. Copie inutili che occupano solo più spazio su disco e creano confusione

tra l'ultima versione approvata e la versione 'veramente' usata in un dato lavoro.



Settembre 2008

5 / 16

frutta 1 mm a sinistra. Questa Ristampa Con Cambiamenti (RRWC) potrebbe richiedere

un nuovo ciclo di approvazione.

Se effettivamente l'esecuzione della modifica richiede la creazione di un nuovo disegno

(che quindi nasce separandosi da quello precedente), viene creato un nuovo Prodotto.

Esempio: modifiche al logo o a un'immagine, o cambiamenti nel testo. Il nome

(solitamente un numero) di questo nuovo Prodotto (in realtà una nuova variante) può

essere definito dal sistema informativo aziendale oppure in fase di prestampa. Se il

vecchio disegno non viene più riordinato dal cliente, questo può essere un motivo per

eliminarlo dal database Prodotti (oppure lo si può mantenere ma definire uno stato

'vecchio' o 'inutilizzato' e assegnarlo al disegno).

Un altro scenario è quello in cui il lavoro si riferisce ad uno o più nuovi Prodotti, o ad un

mix di uno dei tipi di ordine precedentemente descritti. In questo caso l'operatore prepara

prima il disegno per la stampa (correzione delle separazioni, aggiunta dei codici a barre,

creazione dei sormonti, verifica del rifilo e della fustella, ecc.) e successivamente questo

file in produzione diventerà un Prodotto BackStage vero e proprio. Questo può essere

fatto in modo manuale, o può fare parte delle attività di automazione del wo kf ow.

i prodotto

o,

re che si occupa

del layout della lastra si metta a cercare la risorsa corretta.

r l

Le applicazioni di editing quali PackEdge (trattamento dell'elemento o pagina singola) e Plato (layout

della lastra) sono già integrate con il concetto di Prodotto: l'operatore viene guidato ai file d

rilevanti all'interno del lavoro che ha aperto. L'integrazione verrà aggiunta anche in ArtPro. In Plat

dove si effettuano le ripetizioni del Prodotto per creare il Lavoro, il menu di griglia offre la possibilità

di caricare uno o più Prodotti del lavoro. Anche qui, non c'è bisogno che l'operato



Settembre 2008

6 / 16

Immagine 4: ‘Parti’ di Prodotto

Un Prodotto può essere composto da più ‘parti’. Un esempio tipico sono le etichette stampate sia sul

'etichetta

fronte che sul retro. Questi due lati possono essere collegati a 2 diversi file PDF di produzione, ma

dopo varie fasi di stampa o dopo la finitura, diventano un unico prodotto quando arrivano nel

magazzino del trasformatore. Un altro esempio di un prodotto composto da più ‘parti’ è un

per il retro di un confezione, con un fascicoletto incollato ad essa.



Settembre 2008

7 / 16

Immagine 5: proprietà di un Prodotto

Il Prodotto è composto di 2 parti. Qui sono mostrate le proprietà generali del Prodotto (Impostazione

del Prodotto): naturalmente il nome e il codice identificativo, il cliente ed il nome che il cliente dà a

questo prodotto, i campi personalizzati per la categorizzazione ed il filtraggio, una descrizione

testuale e lo stato (se identico a quello di tutte le altre parti).



Settembre 2008

8 / 16

Immagini 6 e 7: proprietà di una parte

di un Prodotto

uesta immagine mostra le proprietà della prima parte del Prodotto. È selezionata la scheda

‘Status’. Da qui è possibile vedere che questa parte è approvata. Una parte di Prodotto può essere

approvata manualmente o automaticamente, nel caso in cui l'approvazione sia stata richiesta tramite

WebCenter.

Q



Settembre 2008

9 / 16

Questa immagine mostra le proprietà della seconda parte del Prodotto. È selezionata la scheda

‘Barcode’. È possibile controllare il codice a barre e inserirlo nello sfondo con una operazione

dedicata.



Settembre 2008

10 / 16

Immagine 8: effetto sulla struttura dati

Il fatto di non avere più una copia dei dati relativi ad un elemento o ad una pagina singola tenu

una cartella

ti in

che rappresenta l'ordine di lavoro, consente di organizzare il server dei dati in un modo

diverso. L'interfaccia dell'operatore ora è composta principalmente dai datab se, e la struttura ad

albero del disco è sensibilmente diminuita in complessità. Sin dagli albori del DTP, le aziende hanno

cercato di gestire meglio che potevano l'organizzazione dei dati; spesso hanno dovuto adattarsi alle

limitazioni dello strumento che usavano, semplicemente perché non c'era nessun altro modo di

lavorare (non era disponibile il modello basato su database). Ecco perché molti hanno preso

l'abitudine di copiare semplicemente i dati, e perché molti hanno imparato ad assegnare nomi a file

e cartelle secondo precise convenzioni, visto che non vi era nessun altro modo di indicare la storia e

le caratteristiche di ciascun file.

È evidente anche un secondo aspetto: gli ordini di lavoro sono temporanei, i loro dati sopravvivono

fintantoché l'ordine è in lavorazione (alcuni giorni o settimane), per un arco di tempo relativamente

breve. I dati di produzione sono invece dati a lungo termine: la cartella con tutti gli elementi produttivi

è il 'caveau' del reparto di prestampa. I layout di lastra ed i dati RIP possono essere dati a breve o a

lungo termine, con BackStage è possibile seguire entrambe le strategie.

BackStage è sempre stato pensato tenendo presente la struttura dei dati già esistenti; ora, con lo

strumento Products, lo è ancora di più. I clienti che utilizzano questo strumento Product sono portati

a separare i dati che appartengono ai Lavori, da quelli che appartengono al Prodotto. Ora, quando

un Prodotto appartiene ad un Lavoro, la connessione viene effettuata tramite un semplice

collegamento tra i database, in modo da poter separare completamente i due alberi di dati, e magari

trattare in modo differenziato anche le relative procedure di backup e archiviazione. Sarebbe infatti

logico archiviare i dati dei lavori, ma mantenere disponibili in linea i dati di Prodotto.

Integrazione JDF/JMF

Un elemento di produzione singolo può essere trasformato in Prodotto BackStage in vari modi: • manualmente (con l'operazione ‘Add to Products’, magari insieme ad altri 200 elementi in

modo massivo, selezionati usando uno strumento intelligente di ricerca) • oppure usando JDF/JMF.

I lavori BackStage già da tempo possono essere creati usando JDF/JMF. Quasi il 10% di utenti BackStage ha già attivato l'integrazione con il proprio sistema informativo aziendale (un MIS personalizzato o già disponibile sul mercato).

a



Settembre 2008

11 / 16

Il passo successivo è ovviamente non solo effettuare la creazione del Lavoro BackStage (con la cartella lavoro blu e con i parametri di ordine di lavoro quali il nome cliente, la data di scadenza,

Lo strumento BackStage Products è in beta dal rilascio di BackStage 7.0 Release 4 avvenuto ad

ecc.), ma ricevere via JDF/JMF anche i nomi dei Prodotti coinvolti in quel Lavoro. Queste informazioni sono importanti per la definizione del Lavoro, e prima di adesso non potevano essere trasmesse in modo digitale. Un comando JDF/JMF può riferirsi non solo ad un elemento esistente nel database dei Prodotti BackStage, ma può anche creare un Nuovo Prodotto. BackStage lo crea nel database dei prodotti, e mostra una icona di anteprima bianca. Successivamente gli operatori di prestampa collegheranno l'oggetto corretto alla definizione del Prodotto. EskoArtwork sta lavorando con diverse software house produttrici di sistemi informativi aziendali, per attivare questa funzione nell'esportazione dei dati JDF/JMF.

agosto 2008. Il rilascio definitivo avverà nella v 7.0 Release 5.



Settembre 2008

12 / 16

BackStage Viewer: un eccezionale strumento di Visualizzazione e Confronto Immagine 1: BackStage Viewer si avvia dal client BackStage Pilot (Mac/Windows)

Se BackStage Viewer può aprire il file, la colonna View offre un collegamento ipertestuale che consente di aprire il file.



Settembre 2008

13 / 16

Immagine 2: I vantaggi degli strumenti di ingrandimento illimitato e di misurazione di

Il file originale (a sinistra) contiene sormonti, nel file di riferimento sormonto è di 0,3 mm. Immagine 3: Analisi delle separazioni con modalità diverse.

precisione

(a destra) non sono presenti. Il



Settembre 2008

14 / 16

Immagine 4 e 5: Confronto ed analisi delle differenze

L'immagine mostra una differenza tipica dopo che un file è stato preparato per la stampa. In questo

ià previste. Naturalmente sa che il testo ha subito uno spostamento e che il

ce a barre è stato aggiunto, così come sono stati aggiunti i sormonti, ma perché quel logo in

cavo sul logo è un errore che

tente sarà ben felice di aver scoperto in questa fase e non in lastra, o peggio ancora, in macchina .

L'immagine precedente mostra le differenze nelle modalità di visio completa; l'utente può

scegliere di visualizzare ‘solo le differenze’ (in basso), oppure di vedere i file fianco a fianco.

caso, l'utente si attende che vi siano delle differenze, ma sta cercando differenze indesiderate,

diverse cioé da quelle g

codi

basso a destra è diverso? L'impostazione errata dell'attributo di s

l'u

ne



Settembre 2008

15 / 16

Immagine 6 e 7: Confronto di una lastra RIPpata con un PDF della singola pagina!

La capacità di BackStage di leggere così tanti formati di prestampa è evidente anche nel programma client, il Viewer. Uno degli aspetti più interessanti del Viewer è la quantità di formati file che è in grado di leggere.



Settembre 2008

16 / 16

BackStage Viewer consente di aprire i seguenti formati file:

• Formati grafici o Esko Normalized PDF (pagina singola), PDFPLA (layout lastra) o ArtPro o PDF o EPS/PS, DCS/EPS o AI - Adobe Illustrator (se compatibile PDF) o Vecchi formati Esko: GRS, PLA e EPF

• Dati immagine o PSD – Adobe Photoshop o EPS o TIFF (< 600 ppi) o Vecchio Esko CT

• Dati RIP o 1 bit TIFF > 600 ppi , LEN o Scala di grigi o DCS 2.0 > 600 ppi

Una volta aperto, qualsiasi file può essere confrontato con qualsias ltro. Alcuni esempi:

• Un disegno iniziale in AI, può essere confrontato con un file di produzione finale (PDF o ArtPro)

• Confronto di versioni o varianti di file di produzione • Confronto del risultato di una ripetizione con una pagina sin ola o un file di ripetizione in

PDF/ArtPro • Ecc...

BackStage Viewer fa parte del modulo Power pack ed è stato rilasci to insieme a BackStage v 7.0

elease 4

i a

g

aR

BACKSTAGE PRODUCTS EN BACKSTAGE VIEWER – FACTSHEET

EG_pr585hinl_BackStage-Factsheet

September 2008

1 / 15

EskoArtwork breidt BackStage uit met view, compare en data management tools1

BackStage Products: geoptimaliseerd job- en gegevensbeheer Schermafbeelding 1: concept en zakelijke logica

BackStage beschikte al over een Jobs-database, die overeenkomt met de orderregistratie database

van het MIS systeem. In BackStage worden de Job orders weergegeven die momenteel actief zijn in

de prepressproductieafdeling. Deze worden met een blauw pictogram aangegeven. “Products” zijn

de afzonderlijke 1-up productiebestanden die bij een bepaalde Job horen. De nieuwe BackStage

Products tool (hieronder ook wel Products-database genoemd) is een database waarin de Products

worden weergegeven die kunnen worden gebruikt voor Jobs.

1 Opmerking: Alle schermafbeeldingen komen van BackStage Pilot, de BackStage client interface die zowel op Mac- als Windows-platforms kan worden gebruikt.



September 2008

2 / 15

Een voorbeeld om het concept te verduidelijken: de BackStage Jobs database kan 77 actieve Jobs

bevatten die moeten worden uitgevoerd. De BackStage Products database daarentegen kan

bijvoorbeeld 20.000 drukklare 1-up productiebestanden (PDF’s) bevatten. Deze productiebestanden

zijn opgewaardeerd tot Products in BackStage, omdat ze mogelijk zullen worden gebruikt voor deze

77 actieve Jobs of voor eventuele toekomstige Jobs.

Bijna alle prepressproductieoperatoren gebruiken nog altijd een papieren print-out voor een uit te

voeren order. Hierop staat vermeld welke productiebestanden moeten worden gebruikt en wat

ermee moet gebeuren. De Products-tool brengt hen nu een stap dichter bij volledig papierloze

communicatie op het gebied van instructies voor orders. En doordat ze dankzij de Products-tool

geen productiebestanden meer hoeven te kopiëren, realiseren ze ook een aanzienlijke

productiviteitswinst.

Schermafbeelding 2: de Product Gallery van BackStage

In de BackStage Product Gallery worden alle Products van de Products-database weergegeven.

Deze kunnen als miniaturen worden weergegeven of in een lijst met meer informatie over de

eigenschappen van de Products. De kleur van de balk geeft de status aan van het Product.

Doorgaans verwijst de kleur naar de goedkeuringsstatus, maar het kan ook een aangepaste status

zijn.



September 2008

3 / 15

Op de bovenstaande schermafbeelding ziet u dat “Funky products” is opgegeven bij Product Filter,

waardoor alleen de Products voor de klant Funky worden weergegeven. Deze weergave kan nog

verder worden gefilterd, zodat bijvoorbeeld uiteindelijk alleen de goedgekeurde voorzijde-etiketten

voor de klant Funky worden weergegeven. Deze filterfunctionaliteit is slimmer en sneller dan de

bestaande zoeken naamgevingsmogelijkheden die vandaag doorgaans worden gebruikt. Huidige

BackStage-gebruikers, die al vertrouwd zijn met de Jobs-database, zullen nu nog vlotter kunnen

werken dankzij de Products-tool. Het was al een fluitje van een cent om een bepaalde Job te vinden,

maar met de Products-tool kunnen ze nu ook gemakkelijk de benodigde productiebestanden vinden.

Voor de BackStage-gebruiker − doorgaans een etikettenproducent of verpakkingsproducent − is een

BackStage Product een drukklaar productiebestand. Hij kan een order ontvangen waarvoor dit

Product moet worden gebruikt. Een producent van etiketten voor bierflesjes kan bijvoorbeeld een

order ontvangen voor het drukken of herdrukken van 24.000 voorzijde-etiketten,

24.000 flessenhalsetiketten, 12.000 Franstalige achterzijde-etiketten en 12.000 Spaanstalige

achterzijde-etiketten. Voor deze Job moeten 4 unieke etiketten worden gebruikt, wat neerkomt op

4 Products. De term “Product” in de context van BackStage mag niet worden verward met de term

die de klant van de etikettenproducent gebruikt voor zijn gevulde flesjes met elk 3 etiketten −

“producten”. “Products” in BackStage verwijzen naar productiebestanden en worden in andere

beheer- en productiesystemen voor etikettenproducenten of verpakkingsproducenten ook wel

“Items”, “Artikelen” of “SKU’s” (Stock Keeping Units) genoemd.

Schermafbeelding 3: Products worden gekoppeld aan Jobs

Op de onderstaande schermafbeelding ziet u hoe een BackStage-gebruiker 4 Products voor

vruchtensapetiketten heeft gekoppeld aan Job “66789”. Hij heeft in de orderinstructies gelezen dat

voor deze Job deze 4 Products moeten worden gebruikt. Hij zal nu de verdere instructies voor de

uitvoer lezen. Rechts kan hij in de kolom Launch Favorites een van zijn vaak gebruikte taken starten

en onder aan het venster ziet hij welke taken al zijn uitgevoerd voor deze Job.



September 2008

4 / 15

Een van de grote voordelen van de Products-tool is dat de gebruiker door deze 4 Products te

koppelen aan deze Job, deze bestanden niet kopieert maar gewoon een koppeling tot stand brengt

tussen de Products-database en de Jobs-database. Dankzij de Products-tool kan hij dus

snelkoppelingen gebruiken, in plaats van te moeten werken met kopieën. In de gebruikersinterface

wordt aangegeven dat deze 4 bestanden bij Job “66789” horen, maar hiervoor hoefden geen fysieke

kopieën te worden gemaakt. Het nadeel van kopieën is niet alleen dat ze opslagruimte vergen, ze

zorgen ook voor verwarring, doordat het na verloop van tijd niet meer duidelijk is welke kopie de

meest recente goedgekeurde definitieve versie is of welke versie is gebruikt voor een bepaalde Job

enz.

Etikettenproducenten en verpakkingsproducenten ontvangen doorgaans Jobs van de volgende

typen:

De eenvoudigste Job is een nieuwe oplage van bijvoorbeeld 4 bestaande etiketten. Hierbij

hoeft niets te worden goedgekeurd. Het enige wat hier nodig is, is een step-and-repeat-

bewerking om de plaatlay-out vervolgens naar de RIP te verzenden. Een dergelijke Job

wordt doorgaans een Re-Run No Change (RRNC) genoemd.



September 2008

5 / 15

Een tweede mogelijkheid is dat voor een Job een kleine wijziging moet worden

aangebracht in een of meerdere Products. Mogelijk is de wijziging zodanig klein, dat er

wordt beslist dat het geen zin heeft om een nieuw Product te maken. In dat geval

overschrijft de gebruiker het bestaande productiebestand met de versie met de wijziging.

Het is bijvoorbeeld mogelijk dat de naam van het vruchtensap 1 mm naar links moet

worden verplaatst. Voor deze Re-Run With Change (RRWC) is mogelijk een nieuwe

goedkeuringscyclus nodig.

Als wordt beslist dat door de wijziging een variant of nieuwe versie van het ontwerp

ontstaat en dat het oude ontwerp behouden moet blijven, wordt een nieuw Product

gemaakt. Het is bijvoorbeeld mogelijk dat een logo, afbeelding of tekst moet worden

bijgewerkt. De naam van dit nieuwe Product − eigenlijk een variant − kan worden bepaald

door het MIS-systeem of door de prepressafdeling. Meestal is dit een nummer. Als het

oude ontwerp nooit meer zal worden gebruikt voor een Job, kan worden beslist om het te

verwijderen uit de Products-database. Of het kan in de database opgeslagen blijven, maar

dan met een aangepaste status, zoals “Outdated”.

Een vierde scenario is een Job waarvoor een of meer “nieuwe” Products worden gebruikt,

of een Job die een combinatie is van de bovenstaande soorten Jobs. Als een nieuw

productiebestand moet worden gebruikt, dient eerst ervoor te worden gezorgd dat het

ontwerp drukklaar is (correcte kleurscheidingen maken, streepjescode toevoegen,

trappingaanpassingen aanbrengen, zorgen voor correcte snijlijnen/stansvormen enz.).

Vervolgens zal de gebruiker dit productiebestand opwaarderen tot een BackStage Product.

Deze opwaardering kan handmatig worden uitgevoerd of deel uitmaken van de

workflowautomatiseringstaken.

De bewerkingsprogramma’s PackEdge (1-up bewerkingen) en Plato (plaatlay-out) integreren al met

de Products-tool. De gebruiker wordt geleid naar de productiebestanden die relevant zijn voor de

Job waarmee hij bezig is. Een dergelijke integratie staat ook op stapel voor ArtPro. In Plato wordt de

gebruiker voor de step-and-repeat-bewerking voor de Products van de Job gevraagd of specifieke

Products of alle Products van de Job moeten worden geladen. Hij hoeft dus niet te zoeken naar het

correcte bestand of een grote hoeveelheid bestanden te doorbladeren.



September 2008

6 / 15

Schermafbeelding 4: onderdelen (Parts) van Products

Een Product kan bestaan uit meerdere onderdelen (“Parts”). Een typisch voorbeeld van Products

met Parts zijn etiketten waarvan zowel de voor- als achterzijde worden bedrukt. Hiervoor kunnen

2 verschillende productiebestanden (PDF’s) worden gekoppeld aan de Job, maar het is mogelijk dat

deze na meerdere drukstadia of na de afwerking tot één Product worden gecombineerd door de

etikettenproducent of verpakkingsproducent. Een ander voorbeeld van een Product dat bestaat uit

meerdere Parts, is een achterzijde-etiket waaraan een boekje wordt vastgelijmd.



September 2008

7 / 15

Schermafbeelding 5: eigenschappen van een Product

Het Product op deze schermafbeelding bestaat uit 2 onderdelen (Parts). Op de afbeelding ziet u dat

Product Setup is geselecteerd in het venster Product properties. Hier kan de volgende informatie

worden opgegeven: Name (naam van het Product), Product ID (id van het product), Customer Name

(naam van de klant), Customer’s Product Reference (naam die de klant aan dit Product geeft),

Custom Field 1, 2 en 3 (aangepaste velden voor categorisatie- en filterdoeleinden), Description (een

vak voor een omschrijving naar keuze) en Status (dit vak is op de bovenstaande afbeelding leeg,

omdat beide Parts verschillende statussen hebben).

Schermafbeeldingen 6 en 7: eigenschappen van een onderdeel (Part) van een Product

Op de onderstaande schermafbeelding ziet u de eigenschappen van het eerste onderdeel (Part) van

het Product. Het tabblad Status is geselecteerd. De status “Page proofs approved” betekent dat de

paginaproeven zijn goedgekeurd. Een Part van een Product kan handmatig worden goedgekeurd,

maar ook automatische goedkeuring is mogelijk, als de goedkeuring is aangevraagd in WebCenter.


Op de onderstaande schermafbeelding ziet u de eigenschappen van het tweede onderdeel (Part)

van het Product. Het tabblad Barcode is geselecteerd. De streepjescode kan worden gecontroleerd

op de achtergrond door middel van een speciale taak.


September 2008

8 / 15



September 2008

9 / 15

Schermafbeelding 8: gevolgen voor de gegevensstructuur

Doordat gebruikers de 1-up gegevens niet langer naar een map voor de Job hoeven te kopiëren,

kan de gegevensserver op een andere manier worden georganiseerd. Centraal in de

gebruikersinterface staan nu de databases − de Jobs-database en de Products-database, en niet

meer zozeer de boomstructuur van de gegevensserver. Prepressproductieafdelingen hebben er

altijd al naar gestreefd om gegevens zo efficiënt mogelijk te organiseren, maar hierbij stootten ze bij

gebrek aan een databaseconcept op beperkingen. Ze waren dan ook genoodzaakt om telkens de

productiebestanden te kopiëren. Wat betreft het weergeven van de eigenschappen van een bestand,

hebben velen naamgevingsprocedures ontwikkeld voor bestanden en mappen. Er bestond immers

geen andere mogelijkheid. Met de Products-tool is dit nu verleden tijd.

Een ander gevolg is dat Jobs als iets tijdelijks kunnen worden beschouwd. Job-gegevens zijn

kortetermijngegevens, die worden gebruikt zolang de Job actief is. Dit varieert van enkele dagen tot

enkele weken. Product-gegevens daarentegen zijn langetermijngegevens en de map met al deze

productiebestanden is dan ook de “kluis” van de prepressafdeling. Plaatlay-outs en RIP-gegevens

kunnen kortetermijn- of langetermijngegevens zijn. BackStage ondersteunt beide mogelijkheden.



September 2008

10 / 15

BackStage was al compatibel met bestaande gegevensstructuren, maar met de Products-tool is dat

nu meer dan ooit het geval. Klanten die de Products-tool gebruiken, worden aangeraden de Job-

gegevens gescheiden te houden van de Product-gegevens. Wanneer een Product bij een Job hoort,

kan dankzij de Products-tool op eenvoudige wijze een koppeling tot stand worden gebracht tussen

beide databases. Op deze manier is het mogelijk om de boomstructuren gescheiden te houden en

er indien gewenst een verschillende back-up- en archiveringsprocedure voor te gebruiken. Logisch

zou zijn om Job-gegevens te archiveren en Product-gegevens online te houden.

JDF/JMF-integratie

Een 1-up productiebestand kan op twee manieren worden opgewaardeerd tot een BackStage Product:

• handmatig (via de taak Add to Products, mogelijk samen met 200 andere productiebestanden, die u kunt vinden met de slimme zoekfunctie)

• of via JDF/JMF. BackStage Jobs worden al sinds jaar en dag gemaakt via JDF/JMF. Bijna 10 % van de BackStage gebruikers heeft dit al geïntegreerd in hun MIS-systeem (een op maat gemaakt systeem of een van de MIS-producten die op de markt verkrijgbaar zijn). De volgende logische stap is om via JDF/JMF niet alleen de Job in BackStage te laten maken (de blauwe Job Folder en de Job-parameters, zoals de naam van de klant, de deadline enz.), maar ook de namen te ontvangen van de Products die nodig zijn voor de betreffende Job. Dit is belangrijke informatie van de Job-definitie die tot nu toe niet digitaal werd doorgestuurd. Een JDF/JMF-opdracht kan niet alleen een verwijzing bevatten naar een bestaand Product in de BackStage Product-database, maar kan ook ervoor zorgen dat een nieuw Product wordt gemaakt. Het Product wordt dan automatisch gemaakt in de Products-database en BackStage geeft voorlopig een lege miniatuur weer voor dit Product. Later koppelt de prepressafdeling het correcte productiebestand aan dit Product. EskoArtwork werkt momenteel samen met meerdere MIS-leveranciers om dit mogelijk te maken in hun JDF/JMF-exports.

De Products-tool maakt als bètaversie deel uit van BackStage 7.0 Release 4, dat sinds augustus

2008 verkrijgbaar is. De eerste officiële versie van de Products-tool zal worden gelanceerd in

BackStage 7.0 Release 5.



September 2008

11 / 15

BackStage Viewer: uitzonderlijke weergave-/vergelijkingstool Schermafbeelding 1: de BackStage Viewer wordt gestart vanuit de interface van de BackStage Pilot-client (Mac/Windows)

Als de BackStage Viewer het betreffende bestand kan openen, wordt in de kolom View een hyperlink weergegeven waarmee het bestand kan worden geopend.



September 2008

12 / 15

Schermafbeelding 2: onbeperkt inzoomen en nauwkeurig meten

Het oorspronkelijke bestand (links) bevat trapping, het andere bestand (rechts) niet. Door het liniaalpictogram onder Tools te gebruiken, ziet de gebruiker dat de trapping hier 0,3 mm bedraagt. Schermafbeelding 3: kleurscheidingen analyseren in verschillende weergavemodi



September 2008

13 / 15

Schermafbeeldingen 4 en 5: verschillen vergelijken en analyseren

Hier ziet u enkele typische verschillen in een bestand dat drukklaar is gemaakt. De gebruiker

verwachtte hier enkele verschillen: hij wist dat er tekst was verplaatst, dat de streepjescode was

toegevoegd en dat trapping was toegepast. Maar het feit dat het logo onderaan rechts verschilt, is

nieuw voor hem. Dit is een goed voorbeeld van een ongewenst verschil. Dankzij de BackStage

Viewer is deze fout in dit stadium ontdekt, en niet op de plaat, of nog erger, pas op de pers.

Hierboven heeft de gebruiker View both - highlight difference geselecteerd om de verschillen

gemarkeerd weer te geven op het ontwerp, maar de gebruiker kan via View both - only difference

ook alleen de verschillen weergeven (zie hieronder) of via het vijfde pictogram onder Channels

beide bestanden naast elkaar weergeven.



September 2008

14 / 15

Schermafbeeldingen 6 en 7: een geRIPte plaat vergelijken met een 1-up PDF!

Dat BackStage een uitzonderlijk grote verscheidenheid aan verschillende bestandsindelingen kan lezen, blijkt pas echt wanneer de BackStage Viewer wordt gebruikt. Deze tool biedt ondersteuning voor een groot aantal typen bestanden.



September 2008

15 / 15

De volgende bestandsindelingen kunnen worden geopend in de BackStageViewer:

• Grafisch o Esko Normalized PDF (1-up), PDFPLA (plaatlay-out) o ArtPro o PDF o EPS/PS, DCS/EPS o AI (Adobe Illustrator) – indien PDF-compatibel o Oudere Esko-indelingen, zoals GRS, PLA en EPF

• Afbeeldingsgegevens o PSD (Adobe Photoshop) o EPS o TIFF (< 600 ppi) o Oudere Esko CT-indeling

• RIP-gegevens o 1-bits TIFF (> 600 ppi), LEN o Grijswaarden o DCS 2.0 (> 600 ppi)

En wanneer een bestand wordt geopend, kan dit worden vergeleken met elk ander geopend bestand. Enkele voorbeelden:

• Een eerste AI-ontwerpbestand kan worden vergeleken met een drukklaar productiebestand (PDF of ArtPro).

• Versies of varianten van productiebestanden kunnen worden vergeleken. • Gestepte en geRIPte output kunnen worden vergeleken met 1-up of gestepte PDF’s/ArtPro-

bestanden. • Enz.

De BackStage Viewer maakt deel uit van het BackStage Power-pack voor BackStage 7.0 Release 4.

eskoartwork extends backstage with view, compare and data … · 2008-09-15 · eskoartwork...

Documents