FAQ: Seltsame Farbmanagement Meldung beim Öffnen von Projekten

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?

CMS-Warnmeldung
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.

“Neue Ausgabeinstellung” nach Anfügen an das Job Jacket

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

3 Comments FAQ: Seltsame Farbmanagement Meldung beim Öffnen von Projekten

  1. Jens Baranek

    Diese JJs haben die Tendenz, mir langsam, aber sicher auf die Nerven zu gehen. Offenbar ist diese Technologie noch fern davon, ausgereift zu sein.
    Außerdem: Ich kann soviele “Farbkonfigurationen hinzufügen” wie ich will, selbst bei meinen EIGENEN Dokumenten ist dieses Fenster bereits ein Standard-Fenster beim Öffnen von Dateien, von den Dokumenten meiner Kollegen einmal ganz zu schweigen.

    NB genauso lästig: Druckt man ein Dokument, so lässt es sich i.d.R. nicht mehr ohne “Wollen Sie die Änderungen sichern ?” schließen, auch wenn am Dokument selbst nichts geändert wurde.
    Was nützen mir solche Meldungen, wenn praktisch JEDES Dokument nach dem Öffnen ein “geändertes” ist ?

    [Georg Obermayr]: Zum ersten Punkt: Ich weiß nicht, wie Sie Ihr CMS konfiguriert haben und wie weit Sie die Arbeitsplätze Ihrer Kollegen dem angeglichen haben. Möglich ist aber vieles, auch ein penetrantes Auftauchen der Meldung obwohl man sich gar keiner Änderung bewusst ist. Meist ist dann doch “irgendwo” noch ein anderer Stil mit involviert. Ich kenne das aus eigener ärgerlicher Erfahrung. Vielleicht sollte doch CMS-Setup mit JJs angededacht werden?
    Zum zweiten Punkt: Das ist ja logisch: Beim Drucken stellen Sie irgendwas ein, und wenn es nur das Papierformat ist. Dadurch wird die Dokument-Vorgabe für “Drucken” geändert, also muss gespeichert werden. Schließlich soll Ihre letzte Drucken-Einstellung auch beim nächsten Öffnen wieder verfügbar sein.

  2. Jens Baranek

    JJs: Ich bin mir nicht sicher, ob ich mir das antun will. Wie ich es jetzt sehe, ist es nur eine weitere undurchsichtige Fehlerquelle mehr. Die Creativen interessieren so technisch-buchhalterische Maßnahmen meist wenig.
    Wenn man wie wir dann noch ca. 12 verschiedene Tiefdruckanpassungen für diverse Zeitschriften durchzuführen hat, steigt der Aufwand beträchtlich.
    Drucken: Sicher sind Einstellungen im Drucken-Menü dafür verantwortlich. Nur ist dann praktisch jedes Dokument ein “geändertes”, mal ganz davon abgesehen, dass der ausgewählte Drucker oft nicht gespeichert wird.
    Das Warnfenster wird so zum Standard, und das soll’s ja eigentlich nicht sein. Zudem führt ein solches Programmverhalten bei vielen Mitarbeitern dazu, das Fensterinhalte überhaupt nicht mehr gelesen werden. Wer laufend mit sinnlosen Fenstern traktiert wird, klickt irgendwann nur noch blindlings auf OK.

  3. Jens Baranek

    P.S.: Betr.: “Nervensägenfenster” beim Öffnen von Dokumenten – ich habe ein LMAA-Workaround-Script zum Öffnen von Dateien geschrieben und mit einem Tastatur-Shortcut belegt.
    Läuft prima und erfreut sich in unserem Team bereits geschätzter Beliebtheit.
    😉

Leave a Reply

Your email address will not be published. Required fields are marked *