Job Jackets sind eines der innovativen neuen Features von QuarkXPress 7. Neben Funktionen wie Transparenzen und OpenType, die nach längerer Zeit jetzt auch Quark Anwendern zur Verfügung stehen, bieten Technologien wie Job Jackets oder Composition Zones völlig neue Ansätze. Sie stellen sicherlich im Moment auch ein Alleinstellungsmerkmal des Quark Produktes dar. Nach den ersten Monaten des Praxiseinsatzes von QuarkXPress 7 kann ein Blick auf die Job Jackets anhand eines prototypischen „reellen“ Projektes geworfen werden. Dabei sollen sowohl die Vorteile beim Einsatz als auch die verbleibenden Baustellen diskutiert werden.
Job Jackets sind hier ein interessantes Mittel um sicherzustellen, dass alle am Projekt beteiligten Personen und Abteilungen stets mit den aktuellen Vorgaben und Richtlinien für den Dokumentaufbau arbeiten. Sie ermöglichen die gemeinsame Nutzung von QuarkXPress 7 Ressourcen über die komplette Arbeitsgruppe hinweg, mit Echtzeit-Aktualisierung in allen verknüpften Dokumenten.
Ein Beispiel: Erstellt werden soll eine größere Menge an Datenblättern für einen Industriebetrieb. In der Grafik-Abteilung wurde eine Entwurfsvorlage sowie ein Gestaltungsraster entwickelt, in dem bereits verschiedene Vorgaben festgelegt sind. Trotzdem ist es aufgrund einer engen Terminvorgabe notwendig, bereits mit der Satzarbeit zu beginnen, bevor alle Spezifikationen endgültig definiert wurden.
Jede Fachkraft steuert zum Jacket das bei, was er/sie am besten kann: Die Vorstufe die Definitionen für den PDF-Export oder das Farbmanagement. Der DTPler die Stilvorlagen und S&Bs. Der Grafiker die Farbdefinitionen und den Satzspiegel. Der Produktioner legt das Seitenformat-, die –zahl sowie die Menge der maximal zu verwendenden Druckfarben fest.
Was es neu braucht, in einem Workflow der Job Jackets verwendet, ist eine Art „Jacket-Administrator“: Dieser fügt die einzelnen Komponenten zu einem Job Jacket zusammen und vernetzt sie darin zu einer sinnvollen Einheit. Diese Person ist die einzige, die Hintergrundwissen über die genauen Funktionsweisen und Zusammenhänge innerhalb der Jackets benötigt. Für alle anderen ändern sich an der Arbeitsweise nur ein paar Details im Umgang mit QuarkXPress.

Der Layouter erstellt also sein Datenblatt auf Basis der Ticket-Vorlage für Datenblätter. Dadurch wird, immer vorausgesetzt, das Job Jacket ist entsprechend konfiguriert, das Dokument bereits von Beginn an richtig angelegt: Die Seitengröße ist wie vorgegeben, die Zahl der Seiten stimmt. Außerdem ist der Satzspiegel über Randhilfslinien definiert. Das QuarkXPress Layout wird also bereits automatisch richtig eingestellt. Dieses Pre-Setup geht aber noch tiefer: Auch die Definition von Quellen und Ziel für das Farbmanagement, sowie der Rendering Intent für das Softproofing werden bereits durch das Job Ticket vorgegeben!
Das Job Ticket bringt aber unser Datenblatt nicht nur von Beginn an in die richtige Form, es bestückt das QuarkXPress Dokument auch mit den notwendigen Ressourcen: Die Hausfarben und das Farbschema für die Datenblätter sind ebenfalls bereits beim Erstellen des Layouts vorhanden. Dasselbe gilt für Absatz- und Zeichenstilvorlagen sowie für S&Bs. Auch hier stehen die benötigten Einstellungsmöglichkeiten von Beginn an zur Verfügung.
Dadurch, dass all diese Vorgaben direkt aus dem Ticket kommen, und das automatisch, wird eine beliebte Fehlerquellen umgangen: Der manuelle Import veralteter oder fehlerhafter Ressourcen aus anderen, „ähnlichen“ Dokumenten, oder grundsätzlicher: Das falsche Anlegen von Dokumenten.
Diese Konzept der „präventiven Sicherheit“ wird auch bei der Ausgabe weitergeführt: Unter den Menüpunkt Ablage: Jobausgabe können über Job Jackets Ausgabewege vorgegeben werden. Dabei kann es sich sowohl um Ansichts- oder Druck-PDFs, als auch um EPS- bzw. PPML-Exporte handeln. Auch für die Ansteuerung von Ausdrucken auf Druckern können natürlich verschiedenste Stile erstellt werden. Der Befehl „Jobausgabe“ macht aber mehr, als nur das einfache Ansteuern von Ausgabestilen. Diese bekannten Ausgabestile für PDF, EPS, PPML und Druck werden nämlich in sog. „Ausgabespezifikationen“ eingebunden, die einen erweiterten Regelsatz für den Dokumentinhalt definieren. So wird im Vorfeld der eigentlichen Ausgabe auch auf verwendete Bildfarbräume, Bilddateiformate, Farbdichten, Überdruckungsmethoden und die Einhaltung von Auflösungsgrenzen bei Bildern (momentan leider nicht getrennt für Strich- und Halbtonmotive) geprüft. Diesen Vorgang hat Quark „Layout-Evaluierung“ getauft. In der Tat sind Job Jackets die Einführung eines neuartigen Konzeptes für Preflighting: Sie arbeiten vorbeugend bereits beim Erstellen eines Dokuments sowie bei der Ausgabe. Gerade hier zeigt sich ein Unterscheid zum PDF-Preflight: Dieses greift ja erst, wenn die Druckdaten bereits erstellt sind, Korrekturmöglichkeiten sind zwar auch hier noch vorhanden, jedoch begrenzt. Ein Preflight, welches bereits im Layout-Programm arbeitet, ist daher immer sinnvoller, weil es eben schon verhindert, dass überhaupt fehlerhafte Druckdaten erzeugt werden. Grundsätzlich gilt also: Je früher im Workflow Prüfungen durchgeführt werden, desto einfacher und nachhaltiger ist die Beseitigung von Fehlern.

Ein Check durch QuarkXPress 7 kann aber nicht eine separate Prüfung auf PDF-Ebene ersetzen: Die Frage ist, welche Information steht an welcher Stelle des Workflows zur Verfügung? Ein QuarkXPress-Preflight kann andere Dinge finden als ein PDF-Preflight. Umgekehrt sind aber auf PDF-Ebene auch wieder andere Informationen verfügbar, die in QuarkXPress so nicht abgreifbar wären. Ein gesondertes Preflight in beiden Programmen ist daher auf jeden Fall notwendig, wenngleich große Schnittmengen zwischen beiden Technologien bestehen. Daran sollte sich auch die Gestaltung der Prüf-Profile ausrichten. Außerdem überprüfen Job Jackets zur Zeit nicht den Inhalt importierter Vektor-EPS Dateien. Gerade in solchen Konstellationen ist es notwendig, hier im PDF noch mal genauer hinzuschauen.
Job Jackets erlauben nicht nur eine einfache Prüfung auf die oben genannten Kriterien, es ist auch möglich, ähnlich dem callas PDF-Preflight, eigene Regelsätze zu definieren. Dadurch ist es etwa denkbar, die Basis-Prüfungen der Ausgabe um projektspezifische Spezifikationen zu erweitern. Das können sowohl Regeln für Überdrucken, Haarlinien, Schriftgrößen, Farbverwendungen u. a. sein, aber auch z.B. für Textüberläufe, einem Fehler, der so nur auf QuarkXPress-Ebene zu finden ist. Wenn man sich von dem Gedanken rein PrePress basierter Regeln etwas löst, ist hier noch weit mehr Potenzial vorstellbar: Im Datenblatt-Projekt könnte explizit auf die Verwendung von best. Schriftarten oder Schriftgrößen geprüft werden. Es ist durchaus möglich, diese Regeln auch erst im Laufe der Projekt-Umsetzung einzuführen, um flexibel auf Änderungen der Vorgaben zu reagieren. Wie bei den anderen Komponenten eines Job Jackets gilt auch bei Regeln, dass diese über die Arbeitsgruppe gemeinsam genutzt werden. Bei der Jobausgabe kommen also immer die aktuell hinterlegten Spezifikationen zum Tragen.

Fassen wir noch mal konkret am Beispiel zusammen: Job Jackets sorgen dafür, dass das Datenblatt automatisch vier Seiten und ein spezielles amerikanisches Format hat. Sie konfigurieren das Farbmanagement des Dokumentes wie gewünscht. Auch die korrekten Hausfarben und Stilvorlagen kommen über Job Jackets richtig in das Dokument. Bei der Ausgabe prüfen sie auf Einhaltung verschiedenster Vorgaben und steuern von selbst den richtigen Ausgabestil an.
Ein konkreter Fall: In der Mitte des Projekts ändert sich die Farbdefinition für die Hausfarbe von HKS auf Pantone. Ohne Job Jackets müsste jetzt in allen Datenblättern manuell die Farbe geändert oder neu angefügt werden. Das ist zeitaufwändig und fehleranfällig. Mit Job Jackets gestaltet sich dieser Vorgang einfacher: In einem der verknüpften Dokument wird einfach die Farbdefinition geändert (natürlich muss diese eine Ressource des Job Jackets sein). Dadurch ändert sich in allen ebenfalls verknüpften Dokumenten automatisch die Farbe mit! Dieser Ablauf ist wesentlich sicherer, da sich niemand mehr um die Aktualität und Richtigkeit der verwendeten Ressourcen kümmern muss. An dieser Stelle zeigt sich aber auch ein momentaner Schwachpunkt der Technologie: Bis Version 7.02 von QuarkXPress ist kein Rechtemanagement in die Job Jackets integriert. Das heißt, jeder kann wissentlich oder „aus versehen“ Ressourcen von Job Jackets ändern und somit auch das Erscheinungsbild oder Verhalten anderer Dokumente entscheidend beeinflussen. In zukünftigen Versionen der Job Jackets muss (und wird) Quark daher zwingend ein Rechtesystem einbauen, um solchen unautorisierten Änderungen vorzubeugen.
Auch im Ausgabe-Bereich sind ähnlich elegant Workflow-Änderungen zu erreichen: Wechselt z.B. das Zielprofil für Farbtransformationen (etwa von ISO Coated auf einen Hausstandard) kann dies über Job Jackets von selbst auf alle abhängigen Dokumente abgebildet werden. Konventionell müssten hier Stile ausgetauscht werden, Altdaten könnten übersehen werden usw. Das hier vorhandene Fehlerpotential wird mit Job Jackets fast im Keim erstickt.
Regeln bieten ebenfalls ein nicht zu unterschätzendes Steuerungs-Potential: So kann darin etwa das verwenden von (z.B.) JPG-Bilddaten oder Lab-Farbräumen verboten werden. Hier erhalten Job Jackets auch einen gewissen „Erziehungs-Auftag“ für eine bestimmte Art der Datenhaltung oder Arbeitsvorbereitung.
Job Jackets unterstützen den evolutionären Prozess, den grafische und technische Festlegungen während der Auftrags-Arbeit oftmals nehmen und vereinfachen deren Durchsetzung.
Die Auseinandersetzung mit Job Jackets lohnt sich also. Auch wenn es auf den ersten (und zweiten) Blick schwierig ist, dass Geflecht von Tickets, Ticket-Vorlagen und Jackets zu entwirren und die Zusammenhänge im Job Jacket Manager zu durchschauen. Man darf nicht vergessen, dass es sich quasi um eine Version 1.0 der Technologie handelt, so gibt es auch noch einige Stolpersteine und konzeptionelle Probleme. Trotzdem sind Job Jackets bereits heute sehr praktikabel, der gewisse Einarbeitungsaufwand für den Administrator wird wohl spätestens dann amortisiert, wenn sich bei einem Kunden die Hausfarbe ändert…
Georg Obermayr, 10/2006
für cleverprinting.de


