Aus dem Newsletter von PDFX-ready:

PDFX-ready hat heute neue Settings und Prüfprofile für die Adobe Creative Suite 3 und 4 zum kostenlosen Download bereitgestellt:

PDF-Exportstile für Adobe InDesign CS3 und CS4 Farbvoreinstellungsdateien für die Adobe Bridge CS3 und CS4 (bzw. für die Einzelprodukte der Creative Suite) PDF-Prüfprofile für Adobe Acrobat 8 und 9

Diese Settings stellen als Workflow-Version 1.2 die Empfehlung von PDFX-ready für Abläufe auf Basis von PDF/X-1a dar. Zu finden im Download-Bereich:

Adobe CS Workflow

Weiterhin wurden zwei neue Dokumente veröffentlicht die Hintergrundinformationen und Empfehlungen für den optimalen PDF-Workflow geben:

Farbmanagement und PDF/X

Ausgabebedingungen

Die Settings für QuarkXPress und PitStop sind in Entwicklung und werden demnächst aufgeschaltet.

Natürlich sind wir (der Arbeitskreis Technik von PDFX-ready) immer an Ihrem Feedback zu den Settings interessiert.

Ist Quark Interactive Designer jetzt das “bessere” Flash? Oder vielmehr Produkt “verschenkter” Ressourcen innerhalb von Quark? Weder noch. Die Intention von Interactive ist weder ein adäquater Ersatz für Adobe Flash noch ist das Produkt so lächerlich, wie es auf den ersten Blick für manche scheinen mag.

Zuerst einmal soll Interactive keine weitere Programmier Umgebung für SWF-Inhalte sein. Die Zielgruppe des Tools sind nicht die Coder oder Flash-Cracks, die schon seit Jahren mit Adobe Flash arbeiten. Zielgruppe sind vielmehr die Designer und Kreativen, für die eine Einarbeitung in das sehr komplexe Programm Adobe Flash bisher nicht in Frage kam, oder gar scheiterte. Interactive hat keine integrierte Script-Sprache und beherrscht auch nicht alle technischen Finessen, die mit Adobe Flash möglich wären.
Dafür kommt die Funktionsweise des Tools auch Grafikern entgegen: Sie müssen sich nicht in eine neue Umgebung einarbeiten, sondern können mit den vertrauten Möglichkeiten und Werkzeugen von QuarkXPress völlig neue Ausgabewege beliefern. Auch die Denke des Programms orientiert sich an den Kreativen: Während die Zeitleiste von Adobe Flash für manche zum Einstieg zu komplex ist, fühlt sich das Seiten- und Objekt-orientierte Handling von Interactive von Beginn sehr intuitiv an, und ist so z.B. auch aus PowerPoint bekannt.
Ein weiterer Unterschied zu Adobe Flash ist, dass Interactive Typo- und Grafikfunktionen bietet (eben die bekannten Funktionen aus QuarkXPress), die in Adobe Flash nur durch den Import von Bildern und Grafiken z.B. aus Adobe Illustrator möglich wären.
Um es also auf den Punkt zu bringen: Quark möchte mit Interactive keine User von Adobe Flash abluchsen, die sind in der Regel ja auch mit dem Programm zufrieden. Aber all jene, denen Adobe Flash bisher zu komplex war (und das sind wohl nicht wenige), aber dennoch Flash (SWF) erstellen möchten, bekommen mit Interactive ein Werkzeug in die Hand, das es schnell und einfach erlaubt, interaktiven Content zu erstellen. Natürlich orientieren sich daran auch die Möglichkeiten des Quark Produkts, mit dem sich eben nicht alle Anwendungsbereiche von Adobe Flash abdecken lassen, da letzteres ja eher in Richtung einer Programmierumgebung geht.

Dadurch, dass Interactive in erster Linie funktioniert wie das restliche XPress 7 können natürlich auch dessen grafische Möglichkeiten voll genutzt werden: Transparenzen, Schlagschatten, OpenType und Typografie, Tabellen usw. Man muss sich also mit keinen neuen Bedienungsfeldern vertraut machen, um Designs aufzubauen. Erst für das Hinzufügen der interaktiven Eigenschaften kommt die neue XTension zum Einsatz.
Weitere Vorteile: Sie müssen kein komplett anderes SWF-Authoring Programm (Adobe Flash Alternativen) erlernen, welches dann im grafischen Bereich evtl. Einschränkungen hat, wie sie von QuarkXPress so nicht bekannt sind (oder umgekehrt). Auch müssen keine Layouts oder Grafiken doppelt in verschiedenen Programmen aufgebaut werden.

Interactive macht besonders extensiv von den neuen Composition Zones von XPress 7 gebrauch – und wäre ohne diese Funktionalität wohl auch nur schwer vorstellbar. Mehrseitige Animationsfolgen und Buttons mit verschiedenen Aussehenseigenschaften werden mittels Composition Zones in das Master-Layout eingebunden und spielen so ihre Funktionalität aus.

Hochinteressant ist der integrative Aspekt von Interactive, der sich so nur in einer Applikation erschließen kann, die es erlaubt, Ausgabe in verschiedenste Kanäle zu lenken. Texte, Bilder und andere Elemente können in einem Print-Layout als synchronisiert markiert werden und dann gemeinsam mit einem interaktiven- oder Web-Layout innerhalb desselben Projektes genutzt werden. Änderungen an der einen Stelle bedeuten somit auch automatisch Änderungen an anderer Stelle. Content muss nur noch einmal zentral gepflegt werden. Selbiges gilt auch für die neuen Composition Zones. Die Möglichkeit, Inhalte mehrfach zu nutzen, steht übrigens nicht erst seit Interactive und XPress 7 zur Verfügung und ist auch für den Satz von Print-Produkten sehr spannend.
Hier zeigt sich einmal mehr: Wer im Geiste mit QuarkXPress 4 weiterarbeitet, dem wird sich keines der neuen Features der letzten XPress Versionen erschließen. Wer nicht bereit ist, seine Arbeitsweisen anzupassen, zieht oftmals auch nur wenig nutzen aus den Updates.

Ähnliches gilt auch für das leidige Thema Web-Layouts: Wie viel wird darüber gelästert und heimlich gelacht! Doch nur wenige erkennen die echten Vorteile für das schnelle Aufsetzen von Prototypen und auch für das einfache WYSIWYG-Webdesign in der vertrauten Umgebung. Einzigartig ist auch die Möglichkeit, ein interaktives Layout in ein Weblayout zu ziehen, ohne dabei vorher als SWF zu exportieren. So können Web- und Flash-Layout zusammen gestaltet werden. Die Wege die XPress hier bietet, sind nicht so rudimentär wie oftmals angenommen. Den Quelltext betrifft dies jedoch nur bedingt…
Sowohl für die HTML- als auch für die Flash-Features von XPress gilt: Möchte ich High-End Anwendungen erzeugen, komme ich um die entsprechenden Profi-Tools nicht herum. Wer jedoch als Kreativer Anwendungen im Mid-End Bereich realisieren möchte, und kein ActionScript u.ä. braucht, der kann mit interaktiven Features von XPress jetzt Sprünge machen.

Der Workflow der Quark hier vorschwebt, war in der Praxis bisher kaum anzutreffen – was jedoch weniger an der Unzulänglichkeit der Implementierung liegt, sondern wiederum mehr an der Denke der Anwender: Erstellen eines Event-Flyers als Print-Layout, gemeinsames Nutzen der Inhalte des Flyers mit einem Web-Layout, welches als Event-Pop Up auf der Website eingesetzt werden soll, und, jetzt neu, gemeinsames Nutzen der Inhalte mit einem interaktiven Layout und Export als Flash-Banner. Als Ausgabewege können somit aus XPress 7 u.a. PDF/X-3, HTML und SWF beliefert werden.
Kann das für Sie ein Weg sein zum einfachen, mehrkanaligen Publishing? Probieren Sie es aus!

Georg Obermayr, Dezember 2006

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

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

Wie ist die Aufgabenverteilung der drei Formate?



Das PDF-Format und dabei besonders PDF/X wird zum Container für den Inhalt einer Druckvorlage. PDF/X wird in zukünftigen Normsätzen auch nicht mehr auf die Limitationen von PostScript besckränkt (z.B. Transparenzen) sein, so dass die Datei dann ohne den Zwischenschritt PostScript vom RIP verarbeitet werden kann. Der nächste Schritt sind sicherlich medienneutrale Workflows, so dass ein PDF den Anspruch erhält in jeder Umgebung sicher wiedergegeben werden zu können, in welcher Art und Weise auch immer.

Im JDF (Job Definition Format) werden die ganzen produktionsrelevanten Parameter erfasst. Also z.B. Medium (Papierspezifikationen), Druckfarben, Formate, Seitenanzahl, Bindungsart u. a. Darüber hinaus kommen auch noch Informationen über den Dateiempfänger, Produktionstermine, Lieferbedingungen, Preisabsprachen usw. in das Job Ticket, der Auftrag wird also darin vollständig beschrieben.

Während im PDF also ausschließlich der Inhalt der Druckvorlage abgelegt wird, liegt im Job Ticket die gesamte Information über die Art und Weise WIE der Auftrag produziert/umgesetzt werden soll.

Dadurch wird hier die Trennung vollzogen zwischen dem Inhalt und der UMSETZUNG des Inhaltes. Ein Flyer kann so z.B. durchaus auch mehrere Job Tickets haben: Bsp. einmal für eine Kleinstauflage im Digitaldruck und einmal für den Offsetdruck in einer größeren Auflage.

JDF basiert auf XML, genauso wie XMP der Plattform für Metadaten, die den dritten Stützpfeiler bildet.

Während JDF den Auftrag definiert, definiert XMP das Dokument. Mit den Metadaten von XMP kann das PDF inhaltlich eindeutig klassifiziert werden und bei Bedarf auch in eine Asset-Management-Umgebung überführt werden. Die XMP-Informationen sind direkt in der Datei angesiedelt, so dass sie nicht irgendwo im Workflow “verloren gehen” können.

Wenn man sich die bisherige Entwicklung anschaut, dann muss man kein Prophet sein um zu erkennen, wie sich der zukünftige Workflow in der Vorstufe definiert:

- PDF ist der universelle Container mit der Beschreibung aller Seiteninhalte, völlig losgelöst vom spezifischen Aufträgen.
- JDF beschreibt den speziellen Auftrag mit allen produktionsrelevanten Parametern.
- Und mit XMP erfolgt die inhaltliche Einordnung des Dokuments auf Basis von XML-Metadaten.

Georg Obermayr, April 2006

Metadaten sind Daten „über“ Daten.

Also jegliche inhaltliche Information über einen Datensatz, die über den bloßen Dateinamen hinausgeht.
Informationen über den INHALT einer Datei. Was wird dargestellt und welche Inhaltliche Bedeutung hat es.

Metadaten werden vom Anwender verstanden und können vom Computer ausgewertet werden!

2. Was ist XMP?

XMP ist ein von Branchenführer und Quasi-Monopolisten Adobe entwickelter und forcierter Standard zur Aufbereitung und Abspeicherung von Metadaten.

XMP basiert auf XML. Über sog. “Costum Panels” könne eigene XML-Schemen entwickelt werden, die auf die spezifischen Bedürfnisse bestimmter Kunden und Branchen abgestimmt sind.

XMP ist noch kein anerkannter Industriestandard, wegen der Marktmacht von Adobe ist XMP jedoch ziemlich zukunftssicher. Nahezu alle aktuellen Versionen der wichtigsten Media-Asset-Management Tools unterstützen XMP.

3. Wieso ist XMP besser?

Die XML-Schemen von XMP werden direkt im Header der Datei abgesichert. Sie werden bereits in der entsprechenden Erstellung-Applikation eingegeben (z.B. Photoshop) und sind dann ein fester Bestandteil der Datei während ihres weiteren Lebenszyklus.

Dadurch entwickeln sich die Metadaten weg vom propritären Abspeichern der einzelnen Asset-Tools hin zu einem offenen Standard der völlig unabhängig von bestimmten Programmen und Dateiformate agieren kann.

Das Innenleben der Datei gliedert sich daher wenn man so will in einen “File-Fork” und einen “Content-Fork”:

Im “File-Fork” sind die spezifischen Informationen des jeweiligen Dateiformates abgelegt, also die Bildpixel, Schriftinformationen, Farbprofile, Vektorbeschreibungen usw. Das differiert von Dateiformat zu Dateiformat.

Im “Content-Fork” sind die XMP-Metadaten abgelegt. Wie gesagt als XML-Schema im Klartext. Die Syntax von XMP ist immer gleich, egal welches Dateiformat.

Die Dateien werde dann ganz normal wie gewohnt im Dateisystem abgelegt. Nur die Eingabe der Metadaten muss natürlich manuell erfolgen, da es sich ja hierbei um Informationen handelt, die kein Computer wissen kann!

Mit XMP ist man an kein bestimmtes Media-Asset-Management Programm gebunden. Je nach Umgebung und Budget kann die Entscheidung individuell gefällt werden. Wichtig ist, dass die Applikation über einen Import/Export Filter für XMP verfügt.
Dadurch ist gewährleistet, dass die XMP-Informationen, die sich bereits in der Datei befinden in die Asset-Management Umgebung integriert werden können.
Und wenn in der Asset-Datenbank etwas an den Metadaten geändert wird, muss sichergestellt sind, dass die Änderungen auch wieder korrekt in den Content-Fork der Ursprungs-Datei zurückgeschrieben werden.

Nur dann ist der entscheidende Vorteil von XMP, nämlich die “Transportfähigkeit” der Daten und Metadaten gewährleistet.

Momentan sind die beiden wichtigsten Programme auf diesen Feld, Cumulus und Portfolio in der Lage dies zu tun (Portfolio aber leider nicht bei PDF-Daten). Auch einige kleinere und größere (Enterprise) Lösungen sprechen bereits XMP. Genauso wie natürlich Adobes eigene Bridge.

Es ergibt sich bei XMP ein Workflow dieser Art:

Die wichtigsten Formate in der grafischen Industrie unterstützen XMP:
TIFF, JPG, EPS Pixelformate sofern sie aus Photoshop kommen.
AI, EPS aus Illustrator. Da Freehand als Programm “tot” ist, erwartet hier niemand mehr eine XMP-Unterstützung.
PDF und Acrobat: Hier gibt es derzeit Diskussionen darüber, verstärkt auf XMP umzusteigen, da bestimmte Informationen (wie z.B. der Trapping-Key) noch im “alten” Info-Dictionary abgelegt werden.
InDesign.
Quark leider noch nicht. Hier besteht aber meine Hoffnung darin, dass Quark umknickt, wenn XMP die entsprechende Marktmacht hat.

4. Fazit

Mit XMP setzt sich ein Trend fort: Geschlossene, propritäre Datenhaltungen sind “out”. Modern ist XML und seine “Tochter” XMP.
Aus meiner Sicht ist es heute wenig zukunftssicher einen Media-Asset-Management Workflow aufzusetzen der NICHT auf XMP basiert.
Nur XMP ist offen, erweiterbar, Programm- und Dateiformat-unabhängig.

Georg Obermayr, März 2006