Ein CMS-Workflow auf Basis von Job Jackets hat nicht nur Vorteile, sondern auch ein paar Nachteile. Diese sind sicherlich auch der Implementierung von Quark geschuldet. Im Moment gilt es aber, um diese Dinge herum zu arbeiten oder aber – falls es gar nicht anders geht – alternative Lösungswege zu suchen.

Der nachfolgende Bug wurde in QuarkXPress 7.2 behoben. Allen Anwendern des defaultjackets.xml sowie verfahrensangepasster Spazial-Jackets wird daher dringend die Durchführung dieses Updates empfohlen!

Bug in Zusammenhang mit defaultjacket.xml
Wird über “Neu von Ticket” auf Basis eines der Job Jackets ein neues Dokument erzeugt, so sind die Konfigurationen für Quelle und Ausgabe nicht richtig gesetzt. Die Evaluierung findet den Fehler. Dies geschieht nur dann, wenn als defaultjacket.xml ebenfalls eines der mitgelieferten Jackets gesetzt wird (etwa das für ISOCoated_v2_eci). Wird dagegen das “leere” Standard-defaultjacket genutzt, so erfolgt auch das CMS-Setup einwandfrei.

Es gibt also zwei Workarounds:
- Wird nur sehr selten auf vom Standard abweichende Ausgabebedingungen zurückgegriffen, so kann das defaultjacket.xml genutzt werden. Dieses sollte dann temporär ersetzt werden, wenn sich am Ausgabeziel etwas ändert.
- Wird in der Produktion mit vielen verschiedenen Ausgabebedingungen gearbeitet, so sollte unbedingt auf ein “spezielles” defaultjacket.xml verzichtet werden. Steuern Sie alle Job Jackets über “Neu von Ticket” an und deaktivieren Sie die mehrfache Nutzung (alternativ kann auch auf Finder-Ebene geschützt werden).

Dieser Bug besteht in Version 7.1. Es ist zu hoffen, das Quark hier in zukünftigen Versionen nachbessert. -> In Version 7.2 passiert!

Entfallener “Neu” Dialog beim erstellen eines Dokuments
Das fällt sicherlich am schnellsten auf: Beim gewohnten Erstellen eines neuen Dokumentes fehlt beim Einsatz des defauljacket.xml der altbekannte Dialog von Seitenformat, Rändern, Spaltenzahlen usw.
Dies ist leider einer etwas unglücklichen Umsetzung von Quark geschuldet: Sobald im Job Jacket konkrete Dokument-Vorgaben gemacht werden (hier konkret Quelle und Ausgabe und Proofing-RI) entfällt dieser Dialog, auch wenn seine Einstellungen hier gar nicht vom Job Jacket betroffen sind!
Das neue Dokument wird automatisch auf Basis der zuletzt »konventionell« erstellten Datei konfiguriert. Wurde zuletzt in A4 mit zwei Spalten auf Doppelseiten gelayoutet, haben auch die zukünftigen Job Jacket-Dokumente dieses Format. Das sollte bedacht werden, um hier eine saubere Ausgangsbasis zu erhalten.
Workaround zu dieser Sache ist das nachträgliche Ändern der Layouteigenschaften bzw. Musterseiten-Einrichtung.

XPert Tools Pro und das defaultjacket.xml

Kommt die neu verfügbare XTension XPert PageSets aus der Sammlung XPert Tools Pro in einer Umgebung mit dem defaultjacket.xml zum Einsatz, gibt es leider eine Inkompatibiltät. Der „Neu“-Dialog der XTension bietet zwar die Möglichkeit Stile für die Dokumenteinrichtung auszuwählen und zu erstellen, jedoch stimmen dann die CMS-Einstellungen des defaultjacket.xml nicht! Das enstehende Projekt hat zwei Layouts: „Layout 1“ mit der korrekten CMS-Konfiguration und „Layout 2“ ohne JJ-CMS-Einstellung. Dafür sind im „Layout 2“ dann die PageSet Einstellungen zum Tragen gekommen.
Es kann also aktuell nur davon abgeraten werden, die XPert PageSets XTension gemeinsam mit einem defaultjacket.xml einzusetzen!

Ändern des Job Jackets für Job Jacket-Laien sehr komplex
Da das Arbeiten mit Job Jackets hier nicht dem gewohnten „Vorgaben-Denken“ der XPress-User entspricht, gestaltet sich die Korrektur des Job Jackets u.U. etwas schwieriger. Möchte man etwa ein anders Ausgabesetting definieren, so muss dieses nicht nur zuerst korrigiert und gesichert werden, sondern auch anschließend im Job Jacket Manager beim entsprechenden Job Jacket zur Anwendung gebracht werden. Das erfordert ein gewisses Hintergrundwissen über die Zusammenhänge und ist auf jeden Fall nochmals ein zusätzlicher Lernschritt.
Auch wenn die notwendigen Schritte relativ simpel zu erklären sind, so dürfte das wohl trotzdem einige bereits abschrecken.

Georg Obermayr, Januar 2007

Zuerst mal ist es wichtig festzuhalten, dass es sich beim defauljacket.xml um kein geshartes Jacket handelt. Für Änderungen bedeutet dies, dass ein zusätzlicher Schritt notwendig ist, um veränderte Ressourcen im Job Jacket zu modifizieren. Außerdem bedeutet dies, dass Dokumente, die bereits auf Basis des unveränderten defauljacket.xml erzeugt wurden ihre Ressourcen auch unverändert behalten! Ein Automatismus zur Übernahme von modifizierten Job Jacket-Ressourcen besteht nur bei gesharten Job Jackets. Ein Einsatz von ihnen macht jedoch für pures CMS-Setup auf Basis von Job Jackets in den meisten Umgebungen nur wenig Sinn.

Vorbereitungen
1. Starten Sie QuarkXPress 7
2. Für die meisten Fälle notwendig: Erstellen Sie ein neues, leeres Dokument auf Basis des zu verändernden Job Jackets.

Ändern des Rendering Intents für das Softproofing
1. Hilfsmittel -> Job Jackets Manager -> Erweiterte Einstellungen
2. Öffnen Sie das zu verändernde Job Jacket (falls noch nicht automatisch geöffnet)
3. Wählen Sie das “Standard Job Ticket” aus
4. Gehen Sie in die Ressource “Layouts” und dort in das “Layout 1″
5. Ändern Sie im Feld “Proof-Intent” wie gewünscht
6. Speichern Sie die Änderung

Hinzufügen von Ausgabestilen (PDF, Druck, PS, EPS) zum Job Jacket
1. Erstellen Sie im leeren Dokument den neuen Ausgabestil. Erstellen Sie vorher ggf. ein zugehöriges Farb-Ausgabesetting.
2. Hilfsmittel -> Job Jackets Manager -> Erweiterte Einstellungen
3. Öffnen Sie das zu verändernde Job Jacket (falls noch nicht automatisch geöffnet)
4. Durch Klick auf das XPress-Programmicon (oben rechts) sehen Sie nun die bestehenden Ressourcen des Programms
5. Wechseln Sie in die Ressource “Ausgabestile”
6. Mittels Drag & Drop ziehen Sie den Ausgabestil aus dem unteren rechten Bereich auf das Basis-Job Jacket (Eine “Hand” erscheint dabei)
7. Aktiveren Sie dann das Job Jacket – Der Ausgabestil ist jetzt auch hier vorhanden
8. Wählen Sie das “Standard Job Ticket” aus (Mit Peil aufklappen)
9. Ändern Sie den Status des Ausgabestils von “In Job Jacket” auf “In Ticket”
10. Speichern Sie die Änderung

Ändern von bestehenden Ausgabestilen des Job Jackets
Leider besteht keine direkte Möglichkeit, bereits importierte Ausgabestile im Job Jacket direkt zu ändern – ausser über einen Texteditor… Daher muss die Änderung vorbereitet und dann neu in das Job Jacket verknüpft werden. Vorgehensweise:

1. Ändern Sie im leeren Dokument den Ausgabestil. Ändern Sie vorher falls gewünscht auch das zugehörige Farb-Ausgabesetting.
Das ist auf direktem Weg leider nicht möglich. Gehen Sie daher unter Ablage -> Exportieren -> Layout als PDF. Wählen Sie den gewünschten Ausgabestil aus, gehen auf “Optionen” und nehmen Ihre Änderungen vor. Wählen Sie dann ganz oben bei “PDF-Stil” “Neuer PDF-Ausgabestil”. Vergeben Sie dann den selben Namen, wie der Stil, denn Sie dadurch ersetzen wollen. Der Ausgabestil taucht dann auch zweimal in der Liste auf, einmal im Job Jacket (fett) und einmal “normal”. Ein Farb-Ausgabesetting kann leider ebenfalls nicht bearbeitet werden, so dass dieser neu erstellt und in den Ausgabestil gebracht werden muss. Achten Sie auch hier, falls inhaltlich erforderlich, auf Namengleichheit.
2. Hilfsmittel -> Job Jackets Manager -> Erweiterte Einstellungen
3. Öffnen Sie das zu verändernde Job Jacket (falls noch nicht automatisch geöffnet)
4. Durch Klick auf das XPress-Programmicon (oben rechts) sehen Sie nun die bestehenden Ressourcen des Programms.
5. Wechseln Sie in die Ressource “Ausgabestile”
6. Mittels Drag & Drop ziehen Sie den Ausgabestil aus dem unteren rechten Bereich auf das Basis-Job Jacket (Eine “Hand” erscheint dabei).
7. Eine Meldung wegen des Namenkonfliktes erscheint falls ein bestehender Stil ersetzt werden soll. Verwenden Sie hier natürlich den neuen Stil.
8. Aktiveren Sie dann das Job Jacket – Der Ausgabestil ist jetzt auch hier vorhanden.
8. Wählen Sie das “Standard Job Ticket” aus (Mit Pfeil aufklappen)
9. Ändern Sie ggf. den Status des Ausgabestils von “In Job Jacket” auf “In Ticket”
10. Speichern Sie die Änderung im Job Jackets Manager und schließen ihn.
11. Löschen Sie den neu erstellten PDF-Ausgabestil wieder aus der QuarkXPress-Oberfläche um spätere Konflikte mit dem Job Jacket Ausgabestil zu vermeiden.

Beachten Sie, dass neue Farbausgabestile auch im Feld “Layouts” des Standard Job-Tickets zum Proof-Profil gemacht werden und dass veraltete Ressourcen aus dem Jacket gelöscht werden sollten.

Ändern von Quelleneinstellungen (Anpassen des RIs oder der Quellen-Standard-Profile)
1. Ändern Sie im leeren Dokument die Quelleneinstellung: Bearbeiten -> Farbeinstellungen -> Quelle…
2. Speichern Sie die Änderung
3. Hilfsmittel -> Job Jackets Manager -> Erweiterte Einstellungen
4. Öffnen Sie das zu verändernde Basis-Job Jacket (falls noch nicht automatisch geöffnet)
5. Wählen Sie dann das Job Jacket des aktuell geöffneten, leeren Dokuments: z.B. das “Projekt 1 Job Jacket”
6. Wechseln Sie in die Ressource “Quelleneinstellungen”
7. Mittels Drag & Drop ziehen Sie die geänderte Quelleneinstellung aus dem Projekt Job Jacket auf das Basis-Job Jacket (Eine “Hand” erscheint dabei).
8. Eine Meldung wegen des Namenkonfliktes erscheint falls ein bestehender Stil ersetzt werden soll. Verwenden Sie hier natürlich den neuen Stil.
9. Wählen Sie das “Standard Job Ticket” aus (Mit Pfeil aufklappen)
10. Ändern Sie ggf. den Status des Ausgabestils von “In Job Jacket” auf “In Ticket”
11. Speichern Sie die Änderung im Job Jackets Manager.

Falls Ihnen noch andere gängige Änderungs-Situationen fehlen, wenden Sie sich gerne an mich.

Georg Obermayr, März 2007

Hier habe ich ein entsprechendes Job Jacket zum Auffinden von Deckkräften kleiner 100% sowie von Verläufen zur Farbe “Keine” bereitgestellt.

Folgende Transparenz-Situationen werden durch das JJ auf Grund technologischer Einschränkungen nicht gefunden:

- native Transparenzen in importierten Dateien, z.B. PDF

- angewandte Alpha-Kanäle importierter Bilder

- sämtliche in QuarkXPress 7 erstellte Schlagschatten.

Das sind schlichtweg Einschränkungen der JJ-Technologie bzw. (2+3) inhaltliche Parameter die sich so leider nicht als Regeln definieren lassen.

Nachdem sich bei JJs in diesem Bereich keine globalen Regeln definieren lassen, muss überall da wo Farbe sein kann, nach Deckkraft geprüft werden – einzeln für jede Art von Objekt. Das bedeutet eine relativ hohe Zahl an Regeln was wiederum bei größeren Projekten auf die Performance beim Evaluieren drücken kann.

Folgenden Workflow würde ich empfehlen, wenn eingehende Daten also mittels JJ geprüft werden sollen:
- gelieferte Datei öffnen
- Ablage -> Job Tickets… -> Projekt verknüpfen
- Dort zum JJ navigieren und auswählen
- Wichtig: “Job Ticket mehrfach nutzen” hier deaktivieren oder im Finder die Datei sperren
- Der Erfolg wird bestätigt.

Beim Einbinden sollte vorher darauf geachtet werden, dass kein bereits bestehendes JJ einfach überschrieben wird!

Dann kann über Ablage -> Job Tickets… -> Layout evaluieren die Prüfung durchgeführt werden. Eine Prüfung kann auch vor jeder Ausgabe erfolgen, wenn dies in den Job Jacket Vorgaben so eingestellt ist.

Das JJ ist nicht produktionserprobt und nur bedingt getestet. Verwendung erfolgt also auf eigene Gefahr. Trotzdem wäre ich natürlich an Feedback interessiert ob es funktioniert, oder ob noch irgendwelche Prüfungen fehlen oder Probleme machen usw…

Georg Obermayr, Februar 2007

Ausgabe-Überprüfung
Eine weitere Besonderheit dieser Konfiguration mittels Job Jackets: Vor der Ausgabe findet eine sog. Evaluierung statt, das bedeutet, es werden verschiedene Dinge überprüft. So wird etwa geprüft, ob auch wirklich die richtigen Quell- und Ausgabesettings gewählt sind. Auch hier würde man auf einen potentiellen Konfigurationsfehler hingewiesen, was das Risikopotential deutlich senkt (Ausnahme: bildspezifische Abweichungen). Unsere Job Jackets prüfen zusätzlich noch auf fehlende Bilder oder Schriften und Textüberläufe. Mit Job Jackets könnten noch mehr Dinge überprüft werden – dies soll die Basis sein. Machen Sie sich mit den Möglichkeiten vertraut, um weitere Regeln für Ihre betrieblichen Workflows zu integrieren.

Kein sichtbarerer Handlings-Unterschied
Für den Normal-Anwender ist das CMS in XPress mit diesem Ansatz leichter zu „händeln“. Nach aussen hin ändert sich eigentlich nichts, dafür bekommt man aber einige Vorteile mit. Einzig der Weg „Neu von Ticket“ für Spezialfälle muss neu gelernt werden. Administratoren müssen allerdings ein wenig dazu lernen – siehe Nachteile dieses Konzepts…

Transportables Farbmanagement
Wird das Farbmanagement konvetionell aufgesetzt so kommt es
– bei der Weitergaben von offenen Daten
– und bei Modifikationen an der CMS-Konfiguration in der Arbeitsgruppe
zu nebenstehender Warnmeldung beim Öffnen älterer Dokumente. Vorrausetzung ist, dass ein im Dokument verwendeter Farb-Ausgabestil auf Programm-Ebene nicht mehr zur Verfügung steht.

Dies ist etwa bei Druckereien der Fall, die viele offene Daten erhalten. Wird der Farb-Ausgabstil an das Job Jacket des Projekts angefügt , so geht dabei der ursprüngliche Name der Einstellung verloren. Ohne Wissen über die Job-Jacket-Technologie ist der Konfigurationsinhalt dann nur noch schwer nachvollziehbar. Wird der Farb-Ausgabestil dagegen durch die Standardeinstellung ersetzt, geht dabei die ursprüngliche Farbkonfiguration des Datenerstellers verloren!

Möchte man diese Entscheidung nicht der Druckerei überlassen und auch intern die Layouts farblich „fixieren“, dann ist ein Setup auf Basis von Job Jackets ratsam! Dann ist sichergestellt, dass sich das CMS problemlos transportieren lässt und sich unabhängig von Programmkonfigurationen konsistent verhält.

Lerneffekt: Dokumentsetup
Dadurch, dass die Wahl für das konkrete Farbmanagement bei der Dokumenterstellung über das Job Jacket getroffen wird, ist nochmals verdeutlicht, wie der sicherste Weg aussieht, um CMS in XPress zu betreiben: schon bei der Dokumenterstellung und vor dem Layoutaufbau.

Lerneffekt: CMS-Module
Es wird klar, dass das CMS aus Modulen besteht, die auf verschiedenen Ebenen wirken. Die Präferenz definiert die absoluten Basics (CMM, BPC, Vektor-CMS…), die später unabhängig vom Ausgabeweg für alles gelten sollen.
Die Ebene darüber ist die Basis-Konfiguration für den häufigsten Ausgabeweg: das defaultjacket.xml.
Die höchste Ebene sind dann Ausgabewege, die Ausnahmefälle darstellen. Diese werden gesondert und bewusst über das jeweilige Ticket angesteuert.

Georg Obermayr, Januar 2007

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

a) Erzeugen des Job Jackets:
0. Erzeugen Sie ein neues Dokument (oder öffnen eines bestehenden)
Anmerkung: Ist nicht zwingend erforderlich
1. Gewohntes Anlegen von Farbdefinitionen, Stilvorlagen, S&Bs.

2. Wechseln in Hilfsmittel -> Job Jackets Manger.
3. Aktivieren Sie die “Erweiterten Einstellungen”.
4. Erzeugen Sie ein neues Job Jacket über das Ordner-Symbol: “Neues Job Jacket”
5. Definieren Sie einen Speicherort, bevorzugt im Job Jackets Standard-Ordner (wählbar in den Preferences) und wählen Sie eine sinnvolle Benennung.
6. Das neue Job Jacket enthält von Anfang an das sog. “Standard Job Ticket”.
7. Klicken Sie auf das QuarkXPress Symbol in der rechten oberen Ecke des Job Jacket Managers: “Programmressourcen laden”
8. Hinter den einzelnen Ressourcen sind jetzt Zahlen aufgetaucht, welche die Menge der jeweils verfügbaren Settings im jeweiligen Bereich angeben. Ist ein best. Dokument geöffnet, werden auch dessen Ressourcen jetzt angezeigt.

Jetzt gilt es diese Ressourcen dauerhaft in das neu erstelle Job Jacket zu importieren:
9. Wählen Sie den gewünschten Bereich (also Absatz-, Zeichenstilvorlagen, Farben, S&Bs). Selektieren Sie das gewünschte Setting und ziehen es per Drag & Drop auf das neu erzeugte Job Jacket. Wiederholen Sie diesen Vorgang für die einzelnen Bereiche.

10. Wählen Sie das neue best. Job Jacket aus. Sie sehen jetzt, dass diese Ressourcen hier importiert wurden.
11. Gehen Sie im “Standard Job Ticket ” in die einzelnen Ressourcen-Bereiche und stellen bei den jeweiligen Settings von Status “In Job Jacket” auf “In Ticket” um. Dadurch stehen diese Settings beim Erstellen eines neuen Dokumentes von Beginn an zur Verfügung und müssen nicht erst über die “Kollaborationseinstellungen” extra importiert werden.

11. Klicken Sie auf “Sichern” um den Job Jacket Manger zu schließen und das neue Job Jacket zu speichern.

b) Anwenden des Job Jackets
1. Generieren eines neuen Projektes auf Basis des Job Jackets über: Ablage -> Neu -> Projekt von Ticket. Wählen Sie hier das “Standard Job Ticket” das neuen Job Jackets aus.

2. Die restlichen Eingaben über Seitengröße usw. können in diesem Fall nach Bedarf gemacht werden (würden sich aber bei Job Jackets auch vorgeben lassen).

Wie in den Paletten Farbe und Stilvorlagen zu sehen ist, wurden die Ressourcen des Job Jackets importiert und stehen nun von Beginn an zum Arbeiten bereit!

Das Anwenden diese Job Jackets auf ein bereits bestehendes Dokument geht folgendermaßen:
1. Öffnen des best. Dokuments
2. Ablage -> Job Jackets -> Projekt verknüpfen. Wählen Sie hier wieder das “Standard Job Ticket” das neuen Job Jackets aus.

Das wars! Jetzt kann in allem mit dem Job Jacket verknüpften Dokumenten mit diesen einheitlichen Stilvorlagen und Farbdefinitionen gearbeitet werden.

Welchen Vorteil bringt dieses Handling jetzt im Vergleich zum konventionellen “Anfügen”?
Auf den Punkt gebracht: Änderungen in diesen Settings ziehen keinen endlosen Rattenschwanz in anderen Dokumenten nach sich!
Beispiel: In einem mit dem Job Jacket verknüpften Dokument wird die Definition für die Stilvorlage geändert (z.B. der ZAB). Konventionell müsste jetzt in allen ähnlichen Dokumenten die Stilvorlage manuell geändert werden: Zeitaufwändig, fehleranfällig und mühsam! Kommen aber Job Jackets zum Einsatz wir diese Änderung automatisch in allen restlich verknüpften Dokumenten reflektiert! Für die Definition von Hausfarben und den anderen Dingen gilt das selbe.

Dieser enorme Vorteil wird nur dann zum Nachteil, wenn Änderungen in den Definitionen unbedacht und voreilig durchgeführt werden. Änderungen in anderen Dokumenten sind dann nicht immer erwünscht. Man muss sich also absolut über die Auswirkungen im klaren sein, dann können bei verantwortungsvollem Umgang enorme Vorteile erzielt werden.

Georg Obermayr, August 2006

Download Beispiel Job Jacket

Zum Anwenden des Jackets auf ein neues Dokument geht man in QuarkXPress 7 folgendermaßen vor:
Ablage -> Neu -> Projekt von Ticket -> Mit Durchsuchen zum entzippten Job Jacket gehen und auswählen -> In der Liste der verfügbaren Job Jackets dann das gewünschte Job Ticket auswählen.

Wie gesagt, habe ich versucht, in diesem Job Jacket möglichst viele der möglichen Funktionen abzubilden: Zum Beispiel:

Zwei Ticket-Vorlagen: Standard und Postkarte. Letztere mit zwei Seiten und der Sonderfarbe HKS 14.

Kundenspezifische S&B-Einstellungen, Absatz- und Stilvorlagen, eine Liniendefinition. (müssen über Ablage -> Job Jackets -> Job Ticket modifizieren zur Anwendung gebracht werden).

Voreingestellte Farbmanagement-Settings auf Basis von ISOCoated, mit dem CMYK-Ziel “Rein wie raus”.

PDF/X-1a-Ausgabestil.

Ausgabespezifikationen: Richtlinien für Farbmodi, Dateiformate, Auflösungen usw. Mehrere Regeln, die verschiedene Druck-relevante Parameter im Layout untersuchen (ohne Anspruch auf Vollständigkeit!).

Bei der Definition der Prepress Bereiche habe ich versucht, mich an die gängigen Industrie-Standards zu halten. Es basiert also auf ISOCoated und PDF/X-1a (weil nur CMYK erlaubt ist). Auch die Regeln und Ausgaberichtlinien orientieren sich an den einschlägigen Prüfprofilen in Acorbat.

Es sei aber noch angemerkt, dass es sich um ein Demo Job Jacket handelt. Es wurde daher versucht ein möglichst breites Spektrum an Features aufzuzeigen. Besonders die Vorstufen-Objekte sind bis zu einem gewissen Grad mit Vorsicht zu geniesen, da noch nicht 100%ig praxiserprobt.

Feedback und Kritik zu dem Job Jacket ist ausdrücklich erwünscht. Es ist wichtig, dass jetzt als Beginn eines Prozesses zu sehen, in dem es darum geht, zu definieren, von welcher Art Job Jackets die betrieblichen Gegebenheiten profitieren können, und wie es sich dann konkret implementieren lässt. Dieses Job Jacket soll den Grundstein bilden zu einer weiteren Diskussion.

Noch zwei Hinweise:
Die definierten Farbprofile werden im ZIP-Paket nicht mitgeliefert. Falls sie auf Ihrem Rechner nicht vorhanden sind, können diese auf der Website der ECI (www.eci.org) heruntergeladen werden.
Diese Settings kommen von der Privatperson Georg Obermayr, sie stellen keine Empfehlung oder Richtlinie von bvdm, ECI, oder einer anderen Standardisierungs-Organisation dar. Die Settings sind noch nicht praxiserprobt und bewährt. Jede Benutzung erfolgt auf eigene Gefahr!

Georg Obermayr, 28. Juni 2006

Was ist das Konzept hinter den Job Jackets?

Drei Schlagwörter bringen die Idee auf den Punkt: Zentralisierung, Vereinheitlichung und Rationalisierung.

Job Jackets basieren auf JDF (Job Definition Format) dem Standard für sog. Job Tickets (Weitere Infos unter http://www.cip4.org). QuarkXPress 7 bringt JDF auf die Ebene des Layoutprogramms und erweitert das Konzept hin zum Container für die Sicherstellung von Datenstandards und der Vereinheitlichung von Produktionsworkflows.

Ein “normales” JDF-Job Ticket erhält Informationen z.B. über Job-Nummer, Auftragsname, Seitenzahl, verwendete Farben, Bindungsart, Auflage, Kontaktinformationen (Kunde/Auftraggeber), Papierformat, Papiersorte, Papierlaufrichtung, Liefertermin u.a. Das JDF-File enthält also die Informationen, welche für die kaufmännische und technische Bearbeitung eines Jobs notwendig sind. JDF ist der “digitale Laufzettel” vom Auftragseingang bis zur Auslieferung (zumindest ist das die Intention).

Ein QuarkXPress 7 Job Jacket kann darüber hinaus auch noch viele verschiedene QuarkXPress-Spezifische Ressourcen, sowie die Vorgaben für das Preflight (übrigens genauso XML-basiert wie JDF selbst) beinhalten: Zeichen- und Absatzsstilvorlagen, S&B-Einstellungen, benutzerdefinierte Striche, Listen, Farbdefinitionen aber auch Settings für Farbmanagement und PDF/X- oder Drucker-Ausgabe sowie sog. Ausgabespezifikationen welche Vorgaben machen, z.B. über erlaubte Bildformate, Bildauflösungsgrenzen, Überdrucken-Vorgaben, Farbaufträge u.ä.. Über frei definierbare Regeln lässt sich zusätzlich dazu das Layout auf spezielle Parameter (z.B. fehlende Bilder/Schriften oder Text-Überhang) durchsuchen.

Job Jackets können von verschieden Projekten aus verlinkt und gemeinsam genutzt werden.

Wenn man sich die möglichen Inhalte eines Job Jackets anschaut und dann noch die Arbeitsgruppenfähigkeit in Betracht zieht, dann ahnt man bereits was für ein Potenzial in dieser Technologie steckt.

Ein paar Beispiele: Die Druckvorstufe arbeitet mit einheitlichen Settings für Farbmanagement und PDF-Ausgabe. Sollte der Workflow modifiziert werden, bekommen alle mit dem Job Jacket verknüpften Projekte quasi von selbst die neuen Settings mit auf den Weg. Die Hausfarben von Kunden werden im Job Jacket einheitlich definiert und sind in allen Kundenprojekten gleich umgesetzt. Stilvorlagen und S&Bs von Periodika werden über das Job Jacket einmal angelegt, und stehen dann allen auf Basis des Job Jackets erstellen Dokumenten von Beginn an zur Verfügung. Das hat darüber hinaus den Vorteil, dass, wenn im Nachhinein die Definition einer solchen Ressource geändert wird, z. B. die Korrektur einer Stilvorlage, dann wird in allen Layouts, die sich mit dem Job Jacket verknüpft haben, diese auch geändert (Ein mächtiges Feature, aber auch gefährlich, wenn man sich über die Auswirkungen nicht im Klaren ist, die unbeabsichtigte Änderungen dann später in anderen Layouts zur Folge haben können). Es gibt noch viel mehr Situationen, die vom Einsatz eines Job Jackets massiv profitieren. Im nachfolgenden möchte ich stellvertretend 3 Ansätze diskutieren, wie sie für Agenturen und Druckereien interessant sein könnten.

Zuerst aber ein paar Basics: Funktionsweise und Anwendung von Job Jackets

Dieser Artikel soll keine Beschreibung aller Details der Job Jacket Technologie sein, sondern nur die Grundlagen erläutern, die notwendig sind, um den Einsteig zu finden und um die einzelnen Workflow-Modelle besser zu verstehen.

Eine genaue Beschreibung des Handlings von Job Jackets ist z.B. im X-RAY-Magazine zu finden: http://www.xraymag.com/pdfs/xrv43.pdf

Das Job Jacket (deutsch: Job-Tasche) ummantelt die einzelnen Job Tickets und Ticket-Vorlagen. Auf der Ebene des Job Jackets werden die ganzen Ressourcen und Vorgaben abgelegt (also z.B. Stilvorlagen, Farben, PDF-Ausgabesettings, Preflight-Regeln, Farbmanagement-Vorgaben, Kontaktdaten, Job-Beschreibungen, Layout-Spezifizierungen).

Eine Ebene unter dem Job Jacket liegen dann die einzelnen Job Tickets. Sie greifen auf die Ressourcen des Job Jackets zu und bringen sie im Feld “Layout” zur Anwendung (dieses Feld steht auch nur auf Job Ticket-Ebene zur Verfügung).

Es gibt Ticket-Vorlagen, die als Basis für neue Projekte dienen sowie Tickets, die bereits mit einzelnen Projekten verknüpft sind.

Im Job Jacket können zusätzlich zum „Standard Job Ticket“ beliebig weitere Ticket-Vorlagen angelegt werden, die sich darin unterscheiden, wie sie die Ressourcen des Job Jackets nutzen. Zum Beispiel könnte es zwei Vorlagen geben für Visitenkarten und Flyer: Der Unterschied wäre hier, dass das voreingestellte Seitenformat variiert. Die Ressource dazu liegt auf der Ebene des Job Jackets (in „Layout-Spezifizierung“), die beiden Ticket-Vorlagen greifen dann eben auf zwei verschiedene Layout-Spezifizierungen zu.

Das Job Ticket kann direkt bei der Erstellung des Projekts zur Anwendung kommen (Neu -> Projekt von Ticket) oder bei bestehenden Projekten nachträglich verknüpft werden (Ablage -> Job Jackets -> Projekt verknüpfen, bzw. über die Kollaborations-Einstellungen).

Mit JEDEM verknüpften Projekt wird im Job Jacket EIN Job Ticket assoziiert. D. H. wird auf Basis einer Ticket-Vorlage ein neues Projekt erzeugt, entsteht im Job Jacket automatisch ein neues Ticket, dass explizit mit dem neuen Projekt verknüpft ist (das ist dann auch grafisch sichtbar).

Die nachfolgende Grafik versucht die Zusammenhänge zwischen Jacket, Ticket und Layout nochmals deutlich zu machen.

Download PDF

Workflow 1: Job Jackets für unterschiedliche Druckverfahren und Ausgabewege

Der erste Ansatz, an den man denkt, wenn man beginnt zu planen, wie sich Job Jackets im eigenen Betrieb einsetzen lassen, ist der, den man von den Acrobat Preflight-Profilen kennt: Für die jeweiligen Druckverfahren, Papierklassen und Ausgabequalitäten wird ein eigenes Job Jacket plus Ticket-Vorlage erstellt.

In ein solches Job Jacket gehören neben den Regeln und Ausgabeparametern, also dem, dass auch ein Acrobat-Profil beinhaltet, auch die Voreinstellungen für das Farbmanagement sowie PDF- und Druck-Ausgabestile. Auch hier gilt wieder: Im Job Jacket werden diese Ressourcen abgelegt, die dann in der Ticket-Vorlage verknüpft sind und zur Anwendung kommen.

Über die sog. Layout-Evaluierung wird bei der Ausgabe das Layout auf Einhaltung der Regeln und Ausgabespezifikationen überprüft. Als Resultat erscheint eine Art Preflight-Report aus dem ersichtlich ist, welche Objekte fehlerhaft sind, also gegen die Vorgaben verstoßen. In den Voreinstellungen lässt sich einstellen, wann die Layout-Evaluierung durchgeführt werden soll, z.B. auch beim Öffnen oder beim Sichern. Wenn in einem umfangreichen Layout geprüft wird und viele Regeln definiert sind lässt die Performance teilweise etwas zu wünschen übrig. Das liegt auch daran, dass die Technologie hinter dem Job Jacket Preflight eine andere ist als beim PDF-Preflight, die Prüfung also noch tiefer geht.

Für Druckereien scheint dieses Modell ideal: Sie können ihre Workflows und Standards in Job Jackets fixieren und diese dann an die Kunden weitergeben. Dort werden dann die Dokumente von selbst in der richtigen Art erstellt und die Druckerei hat etwas weniger Ärger bei der Datenübernahme. Natürlich ersetzt ein Job Jacket nicht die Kommunikation mit den Kunden, da sonst besonders im Bereich Farbmanagement Probleme auftreten können, wenn die Arbeitsvorbereitung nicht entsprechend ist. Im Übrigen können die Regeln im Job Jacket zwar ein paar Dinge mehr finden als ein PDF-Preflight, das ersetzt aber nicht die Kompetenz und das Auge des Datenerstellers!

Auch Verlage können so Fortschritte erzielen: Sie versenden Job Jackets mit den üblichen Ausgabespezifikationen, die zusätzlich auch noch Ticket-Vorlagen mit voreingestellten Anzeigengrößen enthalten. So kann vermieden werden, dass Anzeigen im falschen Format aufgebaut und angeliefert werden.

Eines darf man aber nicht vergessen: Die Job Jacket Technologie ist auf QuarkXPress 7 beschränkt! Arbeitet der Datenerstellter z. B. mit InDesign, CorelDraw o. a. dann kann er davon auch nicht profitieren. Wahrscheinlich werden Job Jackets daher also genauso zum Angebot der Druckerei an die Kunden wie Distiller Settings, Farbprofile oder Preflight-Sets. Nur eben auf einem anderen technischen Level.

Können auch Agenturen oder Satzstudios, die etwas von der Vorstufe verstehen, von diesem Weg profitieren? Auf den ersten Blick ja: Die Jackets werden auf dem Server zentral zur Verfügung gestellt und dann von den einzelnen Arbeitsplätzen aus verlinkt. So herrscht überall der gleiche Arbeitsstandard und bereits in der Entwurfsphase können böse Fehler vermieden werden.
Was mir daran aber weniger gefällt, habe ich bereits angerissen: Für jedes, auf Basis einer Ticket-Vorlage erstellte Projekt wird ein neues Ticket innerhalb des Job Jackets angelegt. Wenn man davon ausgeht das in der Woche ca. 40 Aufträge auf Basis einer solchen Ticket-Vorlage erstellt werden, dann befinden sich nach einem Monat gut 160 Tickets im Job Jacket! Das das nicht mehr zu überblicken und nur noch schwer zu handeln ist, kann man sich vorstellen.

Mein Vorschlag deshalb für rein PrePress-fixierte Job Jackets an Quark: Solche Job Jackets und Ticket-Vorlagen sollten dynamisch mit den Projekten verknüpft werden. Das jeweilige Projekt müsste intern eine Art Link auf die verwendete Ticket-Vorlage haben, sowie Informationen über die verwendeten Spezifikationen bei der letzen Ausgabe. Sollte sich also seit der letzen Ausgabe etwas an den Settings geändert haben, würde der Anwender darauf hingewiesen und kann reagieren.

Workflow 2: Job Jackets für einzelne Kunden

Ein rein PrePress-orientieres Job Jacket nutzt aber auch längst nicht alle Funktionen aus, die durch diese Technologie geboten werden. So kann man, wenn nur nach Ausgabemedien unterschieden wird, nur schwer Gebrauch vom Standardisieren der Hausfarben, Stilvorlagen oder S&Bs für bestimmte Kunden und Projekte machen.

Wenn man dagegen aber Ticket-Vorlagen erstellt, die nur für einzelne Kunden oder Projekte gelten, dann kann auch aus diesen Elementen ein Nutzen gezogen werden. So können z.B. innerhalb einer Zeitschriften-Produktion auf dieselben Stilvorlagen und S&Bs zugegriffen werden. Oder Hausfarben werden über mehrere Projekte hinweg konsistent definiert.

Kunden mit klaren Vorgaben oder auch größere Projekte können von diesem Vorgehen klar Vorteile eintragen. Sollten innerhalb eines Kunden verschiedene Ausgabespezifikationen notwendig sein (z. B. weil auf verschiedenen Papieren gedruckt wird) oder mehrere Arten von Dokumenten möglich sein, müssen eben mehrere Ticket-Vorlagen erstellt werden.

Eine weitere Möglichkeit ist es, in Job Jackets Dokument-Vorlagen zu definieren. Als Beispiele seien hier eine Postkarte mit zwei Seiten, ein Job mit zwei Layouts oder ein vorbereiteter vier-seitiger Flyer genannt. Im Vergleich zu QXT-Templates kann so eine Arbeitserleichterung bei der Dokumenterstellung entstehen. Trotzdem behalten QXTs ihre Berechtigung z.B. für Seitenköpfe o. ä. vorgefertigte Elemente.

Wenn man Job Jackets im Betrieb flächendeckend einsetzen möchte, dann wird man schnell sehen, dass nicht für alle Kunden ein so gestaltetes Job Jacket sinnvoll ist: Entweder weil die Projektzahl zu gering ist oder die Designvorgaben zu locker definiert sind.

In der Realität von Firmen mit einem breiten Kundenstamm wird sich daher wohl eine Mischung aus beiden Ansätzen durchsetzen: Für große Kunden ein spezielles Job Jacket, dass von allen Funktionen gebrauch macht, für den “Rest” standardisierte Jackets für verschiedene Druckbedingungen. Ausgabespezifikationen und Datenstandards müssen dann aber wieder dezentral in mehreren Job Jackets gepflegt werden, falls sich was ändert.

Bei beiden Ansätzen bleibt aber für mich die Gefahr bestehen, dass nach einer gewissen Zeit “Monster-Jackets” entstehen, die kaum mehr zu überblicken und zu handeln sind. Hier muss die Praxis zeigen, wie sich das daher bewährt.

Workflow 3: Job Jackets auf Bedarf mit einfügen vordefinierter Standards.

Entscheidet man sich gegen den flächendeckenden Einsatz von Job Jackets, dann bleibt immer noch die Möglichkeit diese nur bei Bedarf anzuwenden. Also entweder dem Einladen von Stilvorlagen, Farben usw. von bestehenden Jackets oder aber der Verknüpfung mit Ticket-Vorlagen um an Regeln oder Ausgabedefinitionen zu kommen. Wenn man Job Jackets aber nur einsetzt “wenn man will”, dann verspielt man m. E. ihren größten Vorteil, nämlich der Standardisierung und Vereinheitlichung der Datenerstellung.

Job Jackets: Was wäre noch wünschenswert, was fehlt

Einige der konzeptionellen Themen, die bei der täglichen Arbeit mit Job Jackets auftauchen können habe ich bereits angesprochen. Sicherlich muss man etwas Zeit investieren um sich der Technologie in ihrer Gesamtheit anzunähern. Die Zeit lohnt sich aber, wenn man wirklich beabsichtig, Job Jackets durchgängig einzusetzen.

Die Praxis wird zeigen, wo noch weitere Fallstricke von Job Jackets liegen.
Was etwa bereits aufgefallen ist, ist dass sich die Auflösungsparameter nur global festlegen lassen. Hier wäre eine Unterscheidung in Halbton- und Strich-Bilder sinnvoll und praxisgerechter gewesen. Außerdem wäre es einfacher wenn man Ausgabestile, Stilvorlagen, PDF-Settings usw. direkt im Job Jackets Manager erstellen und editieren könnte. Der jetzige Weg über das Importieren als Programmressourcen ist nach Gewöhnung zwar möglich aber doch etwas kompliziert.

Darüber hinaus möchte ich eines noch feststellen: Quark selbst empfiehlt in dieser (http://euro.quark.com/en/products/xpress/pdf/output_service_providers.pdf, Seite 11) Broschüre, statt PDF/X-Dateien zukünftig wieder offene QuarkXPress Dateien an die Druckereien weiterzugeben. Dem kann ich nur widersprechen. Ein Job Jacket löst keines der alten Probleme mit Fonts und Bildern bei offenen Dateien. Dafür den anerkannten PDF/X Standard links liegen zu lassen, ist selbst bei einer so mächtigen Technologie wie Job Jackets der Euphorie etwas zu viel. Und die Aussage „Let the experts create printable PDFs“ ist geradezu absurd, angesichts von Job Jackets, deren Intention es ja auch ist, ohne Expertenwissen saubere PDFs zu erstellen.

Den ganz großen Praxistest haben Job Jackets auch erst noch vor sich. Es wird sich herausstellen, wie viele Anwender auf Administrator-Ebene den Elan aufbringen werden, sich intensiv mit der komplexen Technologie auseinanderzusetzen. Auch wenn es am Anfang schwierig ist, die Anwendung von Job Jackets im Betrieb wird sich lohnen!

Georg Obermayr, Juni 2006
www.georgobermayr.de