Wegen einer aktuellen Frage in hds habe ich mich entschlossen das Thema “Farbmanagement von Vektor-Daten in XPress 7″ einmal etwas genauer zu beleuchten.
Ausgangspunkt ist eine Vektor-EPS-Datei aus Illustrator CS 2 die verschiedene Finessen enthält. Dazu im Detail mehr an den jeweiligen Stellen.
Die Präferenz, von der in diesem Artikel die Rede ist, findet sich in den Farbmanagement-Vorgaben für Print-Layouts von XPress 7:
Im ersten Schritt deaktivieren wir das Vektor-CMS und geben im Modus “Composite CMYK” aus. Dieser Modus gibt nur 4C aus, Sonderfarben werden in 4C konvertiert. Sollten. Denn bei ausgeschaltetem Vektor-CMS wird das Vektor-EPS unverändert ausgegeben, d.h. hier bleiben die Sonderfarben erhalten!
Das ist die erste Regel des Vektor-CMS: Ist es nicht aktiviert, wird das EPS immer ohne Änderung ausgegeben, unabhängig von dem was mit den Farben im restlichen Dokument passiert.
Die zweite Regeln betrifft das Softproofing (Darstellung der Farben in XPress) von Vektor-Daten: Bei deaktivierten Vektor-CMS findet keine akkurate Farbdarstellung von Vektor-EPSen statt. Deutlich wird das an diesem Screenshot und der Darstellung von Magenta im EPS sowie als native XPress-Fläche:
Aktivieren wir zum Vergleich das Vektor-CMS (und wichtig: laden das Bild neu): Nun “stimmt” das Softproofing des Vektor-CMS mit dem des restlichen Dokuments überein!
Sprich: Ist Vektor-CMS aus, interessiert sich XPress nicht für das Vektor-Bild, die Farbdarstellung erfolgt “irgendwie”. Nur bei aktivem Vektor-CMS wird das Bild überhaupt in die Farbmanagement-Überlegung mit einbezogen. Das ist der Hauptvorteil von aktivem Vektor-CMS.
Was heißt das aber für die Ausgabe?
Wiederholen wir die Ausgabe mit “Composite CMYK” (4C OHNE Spot) bei aktivem Vektor-CMS: Nun sind auch alle Sonderfarben im Vektor-EPS ICC-basiert nach 4C aufgelöst worden.
ABER:
Alle anderen Bestandteile des Vektor-EPS AUCH! Die Folge ist:
- Schwarz/Grau ist 4farbig aufgebaut.
- Vormals reine Farben sind verschmutzt
Die Wandlung von Sonderfarben ist inkonsistent zur Wandlung die XPress bei nativen Sonderfarben-Objekten vollzieht: Erstere erfolgt ICC-basiert, bei der zweiten wird dagegen der Alternate Color Space zugeordnet.
Jedoch ist selbst innerhalb des EPS die Wandlung nicht konsistent, da bei einem Verlauf mit Sonderfarbe auch einfach nur der Alternate Color Space aufgelöst wird (also hier keine ICC-basierte Wandlung)!
Verwenden wir als nächstes eine Farb-Ausgabe die Sonderfarben erlaubt: “Composite CMYK und Volltonfarben”. Jetzt bleiben die Sonderfarben im EPS erhalten. Die Schnittflächen von transparenten Sonderfarben und 4C-Objekten werden aber einfach in 4C aufgelöst.
Für den Rest ergibt sich ein gewohntes Bild: Das ganze EPS wird nach mal via ICC durch die Farb-Waschmaschine geschleudert!
Ähnliches ergibt sich auch bei den Ausgabemodi RGB, Graustufen und DeviceN.
Interessant ist folgendes Detail: Verläufe innerhalb des EPS werden zu Bildern gewandelt und NICHT als Smooth Shading ausgegeben! Diese Bilder haben immer eine Auflösung von 103 ppi! Ausnahme ist auch hier wieder der Verlauf zur Sonderfarbe, dieser wird als einziger in der korrekten Form des Smooth Shadings ausgegeben.
Zusammenfassend: Bei Composite CMYK oder DeviceN Modi ist das Vektor-CMS NICHT zu gebrauchen, da immer das komplette EPS ICC-basiert gewandelt wird und Verläufe zu Bildern werden.
Wie sieht es aber im Modus “Unverändert” aus?
Gemeint ist hier der von PDFX-ready benutzte Modus OHNE geräteneutrale Farbe.
Wird hier das Vektor-CMS aktiviert erhält man ein korrektes Softproofing des Vektor-EPS. Der Clou ist nun, dass die Ausgabe “unverändert” erfolgt. D. h. in das Vektor-Bild wird nicht mehr eingegriffen!
Im Modus “Unverändert” ist es also möglich den Vorteil des Vektor-CMS (korrektes Softproofing) mit einer sicheren Farbausgabe zu kombinieren.
Es kann also NUR beim Einsatz der Stile von PDFX-ready empfohlen werden, das Vektor-CMS einzuschalten!
Sind im platzierten EPS oder PDF übrigens kalibrierte Farbräume enthalten werden diese bei der “unveränderten” Ausgabe dekalibriert. Dies ist wahrscheinlich dem Zwischenschritt PostScript beim PDF-Export geschuldet.
Georg Obermayr, Januar 2008
