Georg Obermayr » FAQ

FAQ: Seltsame Farbmanagement Meldung beim Öffnen von Projekten

Georg Obermayr — Sat, 03 Mar 2007 14:47:17 +0000

F:Beim Öffnen meiner QuarkXPress 7 Dokumente erhalten immer wieder die seltsame Warnmeldung, ob ich die “benutzerdefinierten Farbmanagement-Einstellungen zum Job Jacket des Dokuments hinzufügen möchte”. Was bedeutet diese Meldung, und was heißt das für ein optimales Farbmanagement-Setup in QuarkXPress 7?

A:Fangen wir am Anfang an:
Durch XPress 7 hat sich das XPress-Dateiformat in einem hier relevanten Punkt gewandelt. Die Einführung von Job Jackets als Schlüsseltechnologie nimmt nicht nur Einfluss auf, schon öfter diskutierte Fälle, wie Sharing von Ressourcen, Ausgabeüberwachung oder Dokument-Setup. Job Jackets nehmen auch Einfluss auf das Dokument-verhalten, wenn gar nicht bewusst mit ihnen gearbeitet wird! Das äußert sich darin, dass jedes Dokument ein eingebundenes, internes Job Ticket (und dadurch auch ein Job Jacket) enthält. Es wird klar, das Quark Job Jackets zur Basis-Technologie gemacht hat. In unserem Fall betrifft das jetzt besonders das Farbmanagement, bzw. die Ausgabeeinstellungen.

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

FAQ: Aufspüren von Transparenzen in QuarkXPress 7

Georg Obermayr — Sat, 17 Feb 2007 12:47:18 +0000

F:Immer wieder wird in der Entwurfs-Phase versehentlich die Opazität einer Farbe verändert bzw. werden Verläufe zur Farbe “Keine” gelegt. Oftmals passiert das unbewusst, ohne das ein echter Transparenz-Effekt gewünscht oder notwendig wäre. Wie können in der Reinzeichung solche Konstellationen aufgespürt und bereingt werden, um unnötige Transparenz-Reduzierungen zu vermeiden?

A:Im Gegensatz zu Adobe InDesign hat QuarkXPress 7 keinen einfachen visuellen Indikator um Transparenz-Situationen schnell aufspüren zu können. Job Jackets könnnen hier aber ein probates Mittel sein.

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

FAQ: Die “Farbphilosophie” von PDFX-ready

Georg Obermayr — Sun, 31 Dec 2006 13:07:41 +0000

F:Gibt es eigentlich die Möglichkeit, eine optimale Einstellung in Quark 7.02 für die PDF-Composite Ausgabe vorzunehmen? Wie muß eigentlich ein ideales Ausgabesetting aussehen, um nicht “auf die Nase” zu fallen?

Immer wieder werden solche und andere allgemeine Fragen gestellt. Um die Antworten schneller zu finden und die Übersicht zu bewahren, werde ich diese daher in loser Folge hier nochmals mit aufnehmen. Zu Beginn eine Frage zu PDF-Ausgabstilen in QuarkXPress 7. In meiner Antwort gehe ich auf die sehr interessante Farbmanagement-Philosophie von PDFX-ready ein.

A:Ja, die gibt es. Bevor ich das jetzt alles selber beschreibe, verweise ich auf zwei Quellen, die in letzer Zeit Empfehlungen für QuarkXPress 7 herausgegeben haben:

- PDF/X-Ready (http://www.pdfx-ready.ch/index.php?show=390): Hier gibt es als Download verschiedene PDF-Ausgabestile für Coated, Uncoated, Newspaper u. Webcoated. Was bei PDF/X-Ready fehlt sind die Einstellungen für Quellen sowie für die Präferenzen.

- Die kann man sich aber im Cleverprinting Ratgeber 2007 erlesen: http://www.cleverprinting.de/ (Kostenloser Download)

Dem aufmerksamen Beobachter wird nicht entgangen sein, dass PDF/X-Ready und Cleverprinting unterschiedliche Farbeinstellungen verwenden: AsIs und CMYK. Ich denke, es ist ganz interessant einmal die Philosophien zwischen beiden Einstellungen zu beschreiben:

- Cleverprinting verwendet ein CMYK basiertes Setting. Das ist das, was wir auch immer wieder empfohlen haben. Dadurch werden RGB-Bilder automatisch nach CMYK verrechnet, CMYK wird durchgereicht, Transparenzen werden in CMYK reduziert. Dieser Ansatz ist sehr locker gegenüber verschiedenen Arten der Datenaufbereitung: Es ist möglich einen Teil der Daten medienneutral zu halten und andere Daten vorab in CMYK aufzubereiten. QuarkXPress übernimmt auf Bedarf das Farbmanagement und greift regulierend ein.

- PDF/X-Ready verfolgt einen anderen, restriktiveren Ansatz: Es kommt AsIs mit dem jeweiligen CMYK-Profil ohne geräteneutrale Farbe zum Einsatz. Dabei ist die PDF/X-3 Evaluierung aktiviert. Durch diese Kombination werden alle in QuarkXPress 7 platzierten RGB-Bilder bei der PDF/X-Evaluierung als Fehler gemarkt (untagged RGB ist in PDF/X verboten), die PDF/X-Evaluierung scheitert. Die Philosohpie von PDF/X-Ready ist es also, dass auschließlich CMYK-Daten in QXP platziert werden dürfen, die verfahrensangepasste Datenaufbereitung also bereits in Photoshop (z.B.) erfolgen muss. QuarkXPress 7 soll und darf bei diesem Ansatz außer für das Softproofing nicht mehr farbmanagend eingreifen.
AsIs stellt hier sicher, dass RGB RGB bleibt, was wiederum der PDF/X-Evaluierung nicht “gefällt” und somit eine nicht konforme Ausgabe entsteht.

Beide Ansätze sind denkbar und praktikabel: Binding in Photoshop (PDF/X-Ready) bzw. Binding in Photoshop und/oder in QuarkXPress 7 (z.B. Cleverprinting). Der Anwender muss für sich entscheiden welcher Ansatz für sich und seinen Workflow passender ist. Und dann muss eben überlegt werden, wo im Detail noch Anpassungen an die Gegebenheiten erforderlich sind. Die dritte Möglichkeit, das Binding in Acrobat oder später ist mit QuarkXPress 7 auf Grund verschiedener Einschränkungen im Moment nicht sinnvoll umzusetzen.

Gut zu wissen: PDFX-ready ist ein CH-landesweiter Kompromiss. Besser als diese Norm darf man immer sein! Dies kann auch die Komprimierungen oder das Downsampling betreffen, genaus wie eine mögliche nach CMYK konvertierung von RGB-Bestandteilen. Jeder der also weiss, was er tut, kann die Settings ändern, und etwa Farbverechnungen “aktivieren”. Man muss sich aber bewusst sein, dass dann evtl. unkontrolliert oder unbewusst konvertiert wird, was wiederum die Konfiguration weiterer Settings zur Folge hat.

Georg Obermayr