Von PDFX-ready sind soeben neue PDF-Export Stile für XPress erschienen (Workflow Version 1.2). Die Stile sind in XPress 7.5 und 8 einsetzbar. Kostenloser Download unter: http://www.pdfx-ready.ch/index.php?show=492

Die wichtigsten Neuerungen:

• Es wird jetzt auf PDF/X-1a geprüft. PDF/X-3 wird nicht mehr verwendet.
• Das Downsampling von Bilddaten (Farb-, Graustufen und Strichbilder) wurde komplett deaktiviert. Die Kompression bleibt unverändert.
• Die Farbausgabe erfolgt jetzt nicht mehr “Unverändert” sondern auf Basis von “CMYK”. Somit wird es auch ermöglicht mit RGB-Bildern zu arbeiten. Diese werden dann bei der Ausgabe nach CMYK konvertiert. Es kann aber genauso weiterhin mit CMYK-Bildern gearbeitet werden. Möchten Sie auf RGB-Bilder umsteigen brauchen Sie zukünftig eine Farb-Quelleneinstellung. Wie die konfiguriert sein sollte ist im Rezept zu den PDF-Stilen erklärt.

Wir empfehlen die neuen Settings möglichst bald einzusetzen.

Natürlich freuen wir – die Arbeitsgruppe Technik von PDFX-ready – uns auf Ihr Feedback zu den neuen Einstellungen.

Der Bundesverband Druck & Medien (BVDM) hat vor kurzem ein Update für die Publikation “Farbmanagement in DTP-Anwendungen” veröffentlicht. Der dritte Teil der Serie behandelt die Creative Suite 3 sowie XPress 7. Zusammen mit Florian Süßl von MetaDesign und Sebastian Nafroth von 3f8h.net durfte ich als Co-Autor an diesem Projekt mitarbeiten.
Behandelt werden wieder die drei Workflow-Typen early, intermediate und late binding. Wichtigste Neuerung ist dabei, dass für late binding nun PDF/X-4 (also inklusive Transparenzen) verwendet wird. Da weder XPress 7 noch XPress 8 die native Ausgabe von Transparenzen ermöglichen bleibt dieser Workflow hier außen vor. Die Empfehlungen für XPress 7 stellen für mich die Quintessenz von zwei Jahren CMS in XPress 7 dar. Der Erwerb der toll ausgestatteten grünen Mappe sei daher allen “Farb-Entscheidern” ans Herz gelegt.

http://www.bvdm.org/Publikationen/

—- 1 —-
F: Warum gibt PDFX-ready keine Quelleneinstellungen für XPress 7 heraus?
A: PDFX-ready stellt PDF-Ausgabestile für XPress 7 bereit. Diese beinhalten auch das Farbregelwerk von PDFX-ready, dass eine unveränderte Ausgabe der im Layoutprogramm platzierten und erstellten Farben vorsieht. Im Falle von PDFX-ready machen diese sog. Farb-Ausgabestile ca. 80% einer vorhersehbaren Produktion aus.
Wer auch noch die letzten 20% aus dem XPress 7 Farbmanagement herausholen möchte braucht sog. Quelleneinstellungen. Der Einsatz von Quelleneinstellungen stellt einen reinen Zusatz-Nutzen dar und ist nicht zwingend zur sicheren Ausgabe erforderlich – sofern die von PDFX-ready vorgegebenen Best Practices beim Dokumentaufbau (siehe 2) eingehalten werden!
Darüber hinaus ist die Weitergabe von Quelleneinstellungen nicht so leicht zu bewerkstelligen wie bei PDF-Ausgabestilen und es gibt einige Regeln zu beachten beim Einsatz dieser Settings. Dies hätte in beiden Fällen dem Grundgedanken einfacher Kochrezepte bei PDFX-ready widersprochen.

—- 2 —-
F: Gibt es Probleme, wenn ich ohne an meine Ausgabebedingung angepasste Quelleneinstellungen gemäss PDFX-ready ausgebe?
A: Nein, sofern einige Regeln beim Aufbau der Layouts beachtet werden:
- Im Layoutprogramm werden nur druckfertig optimierte CMYK-Daten platziert. Dabei ist darauf zu achten, dass diese auch wirklich für die jeweilige Ausgabebedingung (Coated, Uncoated, Newspaper usw.) aufbereitet wurden. Für Bilder bedeutet dies, dass sie nur in Photoshop separiert werden (early binding workflow); Vektorgrafiken, Farbflächen, Schriften usw. sind ebenfalls immer gleich in CMYK anzulegen. XPress 7 braucht/soll somit keine Farbkonvertierungen bei der Ausgabe mehr vornehmen.

- Bei CMYK-Elementen sollten verschiedene Ausgabebedingungen nicht miteinander vermischt werden. Sprich ein Dokument für ISO Coated v2 sollte auch nur Bilder im Farbraum ISO Coated v2 enthalten und nicht etwa auch Bilder die für den Zeitungsdruck aufbereitet wurden.

- Obwohl es nicht erwünscht ist, kann es jedoch trotzdem vorkommen, dass XPress 7 unbemerkt Farbkonvertierungen bei der Ausgabe vornehmen muss. Dies passiert immer dann, wenn bei der Transparenzreduzierung verschiedene Farbmodi miteinander vermischt werden. Ist etwa ein RGB-Bild transparent gestellt so wird dieses auch bei der PDFX-ready Ausgabe nach CMYK konvertiert! Um also sicher mit Standard-Quelleneinstellungen arbeiten zu können ist es im Besondern beim Einsatz von Transparenz enorm wichtig verschiedene Farbmodi und Farbräume nicht miteinander zu vermischen! Nur wenn alle Elemente bereits in CMYK (oder Sonderfarbe) platziert sind kann verhindert werden, dass keine unkontrollierten Konvertierungen von RGB nach CMYK stattfinden.

- Mit Standard-Quelleneinstellung ist “QuarkXPress 7.0 Default” gemeint. Wird nichts an der Standard-Farbmanagement Einstellung von XPress geändert ist dies Voreinstellung für alle neuen Dokumente. Werden Daten aus älteren QuarkXPress-Versionen in XPress 7 weiterverarbeitet so müssen diese vorher über eine festgelegte Prozedur konvertiert werden. Dies ist hier im Detail beschrieben.

- Werden Sonderfarben aus den “Pantone Process” Bibliotheken verwendet so fallen diese bei der Ausgabe durch das PDFX-ready Preflight. Um hier PDF-Dateien gemäss PDFX-ready zu erstellen kann momentan nur empfohlen werden auf solche Sonderfarben beim Layoutaufbau zu verzichten, oder aber eine eigene Quelleneinstellung anzulegen (siehe 3).

—- 3 —-
F: Welche Vorteile kann ich aus dem Einsatz von Quelleneinstellungen ziehen?
A:
- Ohne Quelleneinstellungen kein Softproofing! Nur wenn dieses korrekt erstellt und angewandt ist eine akkurate Monitordarstellung der Farben möglich.

Wird gemäß obigen Best Practices gearbeitet ist dies eigentlich der wichtigste Grund. Für alternative Workflows sollte noch folgendes beachtet werden:
- Ist es gewünscht, dass XPress 7 Bilder oder Flächen bei der Ausgabe farbkonvertiert werden so geht dies nur über eine Quelleneinstellungen in der die Rendering Intents passend eingestellt sind.

- Wird mit Bildern ohne eingebundenes Farbprofil gearbeitet gilt für diese das Quellen-Standard-Profil. Beim Softproofing sowie bei eventuellen Ausgabe-Konvertierungen ist es daher wichtig, dass diese Profil-Zuweisung passend vorgenommen wurde.

- Im PDFX-ready Umfeld wird all dies relevant, wenn mit Transparenz gearbeitet wird. Dann können unter Umständen auch bei PDFX-ready Farb-Konvertierung auftreten! Auch hier sollten dann Quellen-Standard-Profile (bei unprofilierten Bildern) sowie Rendering Intents sauber konfiguriert sein – jedoch auch hier nur wenn nicht gemäß obigen Best Practices gearbeitet wird (siehe 2).
Im Zusammenhang mit Transparenz ist in jedem Fall das CMYK-zu-CMYK-Farbmanagement in den Quellen zu deaktiveren – auch wenn der komplette Dokument-Aufbau nur aus CMYK-Elementen besteht!

- Mit einer eigens angepassten Quelleneinstellungen kann das oben angesprochene Problem bei Pantone Farben zuverlässig gelöst werden. Für alle “benannten Farben” und “Druckfarben” kann somit CMYK als Basis- oder Alternativ-Farbraum vorgeben werden.

—- 4 —-
F: Welche Möglichkeiten gibt es Farbmanagement einzurichten?
A: Es gibt im Groben zwei Möglichkeiten in XPress 7 Farbmanagement zu konfigurieren: Das konventionelle Setup (wenn alle Dokumente geschlossen sind) und das Setup auf Basis von Job Jackets. Beide Varianten habe ihre Vor- und Nachteile.
Beim konventionellen Setup kann es vor allem Probleme beim Austausch der Daten geben.
Für das Setup mit Job Jackets gibt es ein Referenz-Projekt in dem auch die Vor- und Nachteile beschrieben werden.

—- 5 —-
F: Was muss zusätzlich beachtet werden?
A: Dokumente aus älteren QuarkXPress-Versionen sollte nicht einfach in XPress 7 mit “neuen” Farbmanagement-Einstellung belegt werden. Zuvor ist es notwendig, das hier beschriebene Prozedere durchzuführen.
Kommt eine eigene Quelleneinstellung zum Einsatz sollte diese gleich zu Beginn bei der Dokumenterstellung ausgewählt werden – noch bevor das erste Bild platziert wird. Nur so ist sichergestellt, dass alle Bilder wirklich das selbe Verhalten in Bezug auf Rendering Intent, Standard-Farbraum und Wandlungen innerhalb eines Farbmodus aufweisen.

August 2007, Georg Obermayr

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

Es gestaltet sich also folgenden Situation: Sie erstellen als Programm-Präferenz eine Softproofing-Einstellung und verdrahten diese entsprechend. Die Einstellung wird zum voreingestellt Softproof aller zukünftiger Dokumente. Soweit so gut, nichts tut sich: Die Softproofing-Einstellung wird zwar in das Dokument mit eingebunden, jedoch nicht in das Job Jacket und ist somit auch nicht Bestandteil der beschriebenen, manifestierten und verifizierbaren Setup-Beschreibung des Dokumentes.

Jetzt passiert eines der folgenden Dinge (ohne Anspruch auf Vollständigkeit):
- Sie ersetzen in der Programmvorgabe, die alte Softproofing-Konfiguration durch eine neue, z.B. auf Grund eines Updates (mit neuem Namen).
- Sie geben das Dokument an jemanden weiter, der dieses Softproofing-Setting bei sich nicht geladen hat, oder anders benannt hat (kann auch die Druckerei sein!).
- Oder eine andere Konstellation, in der das ursprüngliche Softproofing-Setup aus irgendwelchen Gründen als Programmpräferenz nicht mehr verfügbar ist.

Öffnen Sie in einer solchen Situation das Dokument wieder, kommt die angesprochene Warnmeldung:
“In diesem Projekt werden benutzerdefinierte Farbkonfigurationen verwendet, die Ausgabe auf Anzeige und Ausgabe der Layouts haben. Fügen Sie für eine konsistente Anzeige und Ausgabe diese Farbkonfiguration dem Job-Ticket des Projektes hinzu”
Und dann die beiden angesprochenen Möglichkeiten “Hinzufügen zum Job-Ticket” oder “Ersetzen durch Standard-Konfiguration”

Der erste Fall, zum Job-Ticket hinzufügen:
Das wäre eigentlich die zu präferierende Option: Das Softproofing-Setup wird in das Job-Ticket gelegt und damit zur manifestierten und verifizierbaren Einstellung. Im Job Jackets Manager lässt sich nachprüfen, dass der “Ort” gewechselt wurde. Grundsätzlich ist das gut so, denn zukünftige Anwender müssen sich bei oben beschr. Konstellationen nicht mehr mit dieser Meldung herumschlagen, das CMS wurde “transportabel”. Es gibt jedoch einige Dinge, die nicht ganz sauber sind:
- Der Name der Einstellung geht verloren. Diese heißen jetzt kryptisch “Neue Ausgabeeinstellung X”. Das wird dadurch verschlimmert, dass
- auch im Menü Farbeinstellungen -> Ausgabe… die Konfiguration des Settings nicht einsehbar ist.
- Ich somit auch keine Möglichkeit mehr habe, die Einstellung zu verändern.

Einzig über den JJ-Manager wäre eine Info über den Inhalt möglich, eine Modifikation jedoch nicht…

Also sehr ungünstig, besonders wenn viel mit CMS experimentiert wird und Namen/Inhalte von Settings wechseln bzw. Daten weitergegeben werden. Ich habe selbst einige solche Dateien, welche fast unmöglich zu handeln sind.

Der zweite Fall, wechseln auf den Standard:
Hier wäre es wohl aus in bestimmten Fällen wünschenswert, XPress 7 würde auf den aktuell geltenden Standard wechseln. In der Tat wird hier anders gearbeitet. Die für benutzerdefinierte Ausgabe-Setups verfügbaren Modi:
Separation//Host/in-RIP
Composite//Grausufen/RGB/CMYK/AsIs/DeviceN
werden den acht von Quark mitgelieferten Ausgabe-Setups zugeordnet:
Prozess und Vollton, Zu Vierfarbauszug konvertieren/In-RIP Auszüge
Graustufen/Composite-RGB/Composite-CMYK/Unverändert/Zusammengesetze CMYK und Volltonfarben

Nicht der neuer CMS-Standard ist also ausschlaggebend, sondern ein fest verdrahteter Fallback auf Basis von ursprünglichem Ausgabemodus/Farbmodus. Die Denke dahinter ist klar: Wird eine solche Datei weitergegeben, kann nur garantiert sein, dass der Empfänger die acht Standard-Settings besitzt, nicht jedoch den beim Datenersteller aktuellen Standard!

Wird klar, warum bei XPress 7 die Notwendigkeit für diese Meldung entsteht? Ist die ursprüngliche Programmeinstellung nicht mehr vorhanden, muss eine Entscheidung getroffen werden. Wandeln in eine Dokumenteinstellung durch das Job Jacket zur konsistenten Wiedergabe? Fallback auf die fest definierte, verfügbare, passende Programmeinstellung?

Was also tun? Man könnte
- versuchen die Basis-Ausgabeeinstellungen zu hacken…
- Skripte erstellen um nach dem automatischen Fallback auf den neuen “Standard” zu wechseln. Dabei darf aber nichts in das JJ kommen.

- Das CMS-Setup gleich auf Basis von Job Jackets erstellen. Dann wäre diese Meldung von Haus aus unterdrückt, die Darstellung immer konsistent, der Name “lesbar” und das Setting editierbar. Dazu gibt es auf dieser Website ein Projekt mit Downloads und Beschreibungen.

Es wäre der sicherste Weg, um die Integrität der Altdaten zu erhalten und gleichzeitig nicht ständig mit “Neuen Ausgabeeinstellungen” konfrontiert zu werden.

Generell tut sich hier aber ein neuer Problemkreis auf: Das JJ ist ja intern und “abgekapselt” von der Außenwelt. Ändern Sie also etwas an Ihrem “Standard” (was ja durchaus auch innerhalb des Basis-JJ passieren kann), bekommt das bereits bestehende, interne Ticket das nicht mehr mit und geistert im schlimmsten Fall mit veralteten Settings herum. Was es also bräuchte, wäre dann an dieser Stelle wiederum ein Abgleich zwischen internen JJ und Basis-JJ.

Georg Obermayr, März 2007

Wie verhält es sich bei…

… ISOCoated_v2_eci CMYK-Bildern: Die Bilder werden nicht mehr konvertiert und einfach durchgereicht.

… ISO Newspaper CMYK-Bildern (oder anderen vom Standard abweichenden CMYK-Profilen): Die Bilder werden nicht mehr transformiert und einfach durchgereicht. CMYK zu CMYK-Transformationen finden nicht statt und wären im Moment auch nicht sicher umzusetzen. Ort der Normalisierung von CMYK-Farbmodi ist und bleibt Photoshop.

… unprofilierten CMYK-Bildern: Diesen wird das CMYK-Standard-Profil zugewiesen, nicht mehr weiter transformiert und einfach durchgereicht.

… CMYK-Vektoren: werden keinem Farbmanagement unterworfen.

… Graustufen: Analog zu CMYK. Es finden keine Transformationen mehr statt.

… CMYK Normalfarben und Sonderfaben: Normalfarben werden 1:1 ausgegeben, Buchfarben (Vollton wie Prozess) haben Alternate Color Spaces in CMYK.

… RGB/Lab Bilder, Vektoren und Normalfarben: Werden beim Setting für Druck-PDFs 1:1 ausgegeben. Es findet keine Transformation nach CMYK statt! Ausnahme können unter Umständen best. Transparenz-Konstellationen sein. Die Farbmanagement-Philosophie entspricht also der von PDFX-ready, die ich hier bereits besprochen habe. Alle verwendeten RGB-Elemente werden bei der im Ausgabestil verdrahteten PDF/X-3-Überprüfung als fehlerhaft gemarkt. Das resultierende PDF mit RGB-Elementen ist also keinesfalls PDF/X-3 konform! Ort für Farbraumtransformationen und Bindung an CMYK-Ausgabebedinungen ist und bleibt in diesem Workflow Photoshop. QuarkXPress soll und darf außer für das Softproofing keine Farbraumkonvertierungen durchführen.

Workflow-Alternative:
Möglich wäre ein Ansatz, in dem QuarkXPress RGB nach CMKY konvertieren darf. Dazu müsste die CMS-Ausgabe von AsIs auf CMYK umgestellt werden. Sollte dies gewünscht sein, muss die Änderung am Job Jacket selbst vorgenommen werden.

Anmerkungen:
- Die PDF-Ausgabestile entsprechen inhaltlich denen von PDFX-ready. Da PDFX-ready jedoch noch keine Aktualisierung auf das neue ISOCoated_v2_eci durchgeführt hat, wurden die Settings anders benannt um nicht den Eindruck zu erwecken, es handle sich hierbei bereits um einen Standard.

- 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 heruntergeladen werden. Die Graustufen-Profile müssen mittels Photoshop separat erzeugt werden. Die Farbprofile werden auf OS-X durch Ablage in /Library/ColorSync/Profiles oder. /Users/…/Library/ColorSync/Profiles installiert.

- So erstellt man selbst ein Graustufen-Profil in Photoshop (hier CS 2): Bearbeiten -> Farbeinstellungen -> “Mehr Optionen” -> Graustufen -> Graustufen Einstellungen laden -> Das Profil ISOCoated auswählen (oder irgendein anderes, aus dem Sie sich die Graukurve ziehen möchten) -> Dann “Graustufen speichern” auswählen (Im Graustufen-Menü in den Farbeinstellungen von PS).
Anschließend das neue Profil auf Mac in einer der Librarys ablegen, und so QuarkXPress 7 verfügbar machen. Wichtig: Es handelt sich hierbei um kein offizielles Profil und auch um keinen “ultimativen Königsweg” im Umgang mit Graustufen. Die Profile sind selbst erzeugt und werden daher auch auf eigene Gefahr eingesetzt!

- Diese Settings kommen von der Privatperson Georg Obermayr, sie stellen keine Empfehlung oder Richtlinie von bvdm, PDFX-ready, oder einer anderen Standardisierungs-Organisationen dar. Die Settings sind nur bedingt praxiserprobt und bewährt. Jede Benutzung erfolgt auf eigene Gefahr. Feedback ist erwünscht.

Georg Obermayr, Januar 2007