Neue Workflows mit Job Jackets in QuarkXPress 7

In Kooperation mit

Ein Artikel von Georg Obermayr (www.georgobermayr.de). Eines der am meisten beworbenen neuen Feutures von QuarkXPress 7 sind die sog. Job Jackets. Jetzt da sich der Rauch um die Neuerscheinung langsam legt, lohnt es sich, einen genaueren Blick auf diese Technologie zu werfen und zu untersuchen, wie Betriebe der Medienbranche (Agenturen wie Druckereien) davon profitieren können.

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

Browse Timeline