Nachdem ich es ja bereits angedeutet habe kommt hier mein Vorschlag für ein Farbmanagement-Setup in QuarkXPress 7.1

Die Homepage des Projektes ist:
http://www.georgobermayr.de/...gory/best-practices/

Dort findet ihr momentan:

- Die Basis-Anleitung inkl. Download:
http://www.georgobermayr.de/...ups-in-quarkxpress-7

- Eine Beschreibung der Vorteile des Konzeptes:
http://www.georgobermayr.de/...satz-der-job-jackets

- Eine Beschreibung der Nachteile des Konzeptes (unbedingt lesen, da darin eine momentane Abweichung vom oben erläuterten "Idealfall" aufgeführt ist):
http://www.georgobermayr.de/...satz-der-job-jackets

- Eine Überblick über die inhaltiche Konfiguration der Job Jackets und des CMS inkl. Disclaimer:
http://www.georgobermayr.de/...jackets-konfiguriert


Ich hoffe das hilft einigen hier weiter und würde mich natürlich über Feedback, Anmerkungen, Kritik, Diskussion usw. freuen.

Georg Obermayr

Hallo Herr Obermayr,

erstmal: RESPEKT für diese ehrenamtliche Anstrengung.
Eine Frage habe ich spontan. Warum ist das entstehende PDF nicht PDF/X3-kompatibel? Werden RGB-Elemente nicht als ICCBased-RGB in das PDF geschrieben?

Antwort auf [ loethelm ]

Eine Frage habe ich spontan. Warum ist das entstehende PDF nicht PDF/X3-kompatibel? Werden RGB-Elemente nicht als ICCBased-RGB in das PDF geschrieben?

Exakt. RGB-Elemente werden als DeviceRGB in das PDF geschrieben. Daher scheitert die PDF/X-Evaluierung.
Das ist im Sinne des Erfinders und entspricht dem, was PDFX-ready in diesem Bereich praktiziert.
Hier gibt es eine genaue Beschreibung: http://www.georgobermayr.de/...ophie-von-pdfx-ready

Im Kern geht es darum, das im Layoutprogramm keine Farbraumkonvertierungen erfolgen dürfen.
Eben das wird erreicht durch die Ausgabe als DeviceRGB / AsIs und einer gescheiterten PDF/X-Evaluierung.

Das sagt aber nichts aus, darüber ob XPress 7 die Konvertierung nicht auch Qualitativ durchführen könnte. Im Gegenteil: Es handelt sich um die bewusste Workflow-Entscheidung, dass dies nicht unbewusst und unkontrolliert erfolgen darf.

Eine Ausgabe in ICCBased-RGB wäre auch möglich, jedoch gibt es hier das Problem, dass der originäre Profil-Name verloren geht (PostScript CSA).

Georg Obermayr

Antwort auf:

Eben das wird erreicht durch die Ausgabe als DeviceRGB / AsIs und einer gescheiterten PDF/X-Evaluierung.

AsIs bedeutet aber doch nicht, dass RGB-Quellprofile verworfen werden. Macht XPress das in diesem Ausgabemodus immer oder nur bei Ihren Einstellungen, also explizit auf Wunsch?

Antwort auf:

AsIs bedeutet aber doch nicht, dass RGB-Quellprofile verworfen werden. Macht XPress das in diesem Ausgabemodus immer oder nur bei Ihren Einstellungen, also explizit auf Wunsch?

Es gibt bei AsIs in XPress 7 die Option "Geräteneutrale Farbe"
In "meinen" Settings ist diese deaktiviert, was die oben beschriebenen Konsequenzen zur Folge hat.

Würde man das Setting aktivieren, würde im PDF auf Objekt-Ebene getaggt, das RGB-Quellprofil bleibe also erhalten (in den meisten Fällen, leider stark Dateiformat/Farbmodus abhängig in XPress 7).
Gravierendster Stolperstein dieser Verfahrensweise ist aber, dass das ICC-Profil als CSA-Profil in den PostScript-Stream überführt wird und abschließend bei der PDF-Ausgabe wieder zum ICC-Profil wird. Bei dieser Konvertierung geht jedoch der originäre Name des Farbprofils verloren. Dei Namenskonvention lautet dann auf "Profile xxxx from PostScript CSA".
D.h. Sie sind im resultierenden PDF nicht mehr in der Lage, die verschiedenen Quellprofile voneinander zu unterscheiden. Spätere Farbkonvertierungen basieren also z.T. immer auf Vermutungen, was besonders im Datenaustausch sehr viel Vertrauen erfordert...

Georg Obermayr

Hallo loethelm,

der "AsIs" Ausgabemodus von QuarkXPress 7 lässt beides zu - eine geräteabhängige Ausgabe in Device-Farbräumen und eine geräteunabhängige Ausgabe in CieBased-Farbräumen (aus deren CSAs dann im PDF ICCBased-Farbräume werden).
Die eigentlichen ICC-Quellprofile verlieren Sie aber auf alle Fälle, da PostScript keine ICC-Profile unterstützt und QuarkXpress 7 keinen nativen PDF-Export kennt.

Hallo zusammen,

verstanden, danke :-)

Ich habs aber noch nicht ganz verstanden.

Was ist denn nun der Vorteil des DeviceRGB im PDF gegenüber der Umwandlung in Quark XPress?
Wenn es NICHT beabsichtigt ist, in CMYK umzuwandeln, dann brauche ich doch das ganze PDF nicht, da wir ja von Druckvorstufe reden, wo CMYK benötigt wird, oder?

Und wenn ich in CMYK umwandeln möchte, dann habe ich mit DeviceRGB das Quellprofil verloren, womit eine saubere Umwandlung entweder in Photoshop, Quark oder PDF geschieht.

Wenn also (wie bei dem Comments in Georgs Block) von PDFX-ready keine unkontrollierte Umwandlung im Layoutprogramm erfolgen soll, dann wäre es doch besser, kein PDF zu erstellen, sondern die PDF-Erstellung abzubrechen, da ja auch der PDF/X-Check nichts wird.

?

Hallo,

dass der PDF/X-Check schief geht ist gewollt und soll darauf hinweisen, dass da was im Argen liegt. Die Quellprofile sind ja in den platzierten Originalen noch vorhanden (wenn sie jemals da waren ;-) ) und der Nutzer soll die RGB-CMYK-Transformation im Original in Photoshop machen, in XPress aktualisieren und dann erneut exportieren, um die Kontrolle über die Transformation zu behalten.

Aha.

Der Nutzer soll also wirklich erst bei der PDF/X-Validierung erst feststellen, dass RGB-Daten vorhanden sind, dann das PDF in den Papierkorb und in Photoshop RGB->CMYK.

Wäre es denn dann nicht sinnvoller, gleich die PDF-Ausgabe zu verweigern, das müsste doch über die JobJackets irgendwie funktionieren.

Aber das Prinzip hab ich jetzt verstanden.

Danke

Hallo Herr Nagel,

glauben Sie im ernst, dass Quark oder selbst Adobe in absehbarer Zeit in der Lage sein werden, ein RGB-Bild, welches versehentlich in eine platzierte EPS- oder PDF-Datei eingebaut wurde, per ins Layoutprogramm integrierter, nicht PDF-basierter Prüftechnologie zu identifizieren?
Egal über welchen Hersteller wird sprechen, wenn es um absoluten Tiefgang bei der Datenprüfung geht, dann kommt man als Anwender nicht an einer PDF-basierten Prüfung vorbei.

Hallo Herr Zacherl,

okay, ich muss zugeben, an die tiefergehenden Dinge wie EPSe und dergleichen hab ich jetzt gar nicht gedacht.

Nun scheint mir der Weg auch logisch und habe wieder mal etwas mehr von der Philosophie von PDF/X-Ready verstanden.

Vielen Dank

hallo Georg,

was so alles in Schulbaden rumliegt ;–)

Ich hab es mir mal angesehen und durchgetestet. Hier das, was mir auffiel:

Nach dem Bearbeiten der Quellprofile in der Anleitung muss es heißen … Lust but not least gehen sie unter Bearbeiten–>Farbeinstellungen–>*Ausgabe* … (statt *Quelle*).

Da in diesem Forum immer wieder empfohlen wird, den Präferenzen-Ordner in den QXP-Ordner zu verlegen, würde ich das auch hineinnehmen.

Das Programm muss geschlossen und wieder geöffnet werden, damit die neuen JobJackets zur Verfügung stehen.

Da die verwendeten Profile in den JobJackets nicht enthalten sind, wendet sich diese Anleitung an fortgeschrittene User.

Für Einsteiger muss auch die Beschaffung und Speicherung der Profile beschrieben sein. Die Profile für den Farbraum *Grau* können ja mitgeliefert werden, um den Usern die Erstellung zu ersparen.

Ein Hinweis darauf, dass es sich ausschließlich um Print-Profile handelt, sollte auch nicht fehlen.

Bei Erstellung eines neuen Dokuments auf Basis eines anderen JobJackets wird ein Regelverstoß angezeigt, weil die Voreinstellungen damit nicht übereinstimmen. D.h., man muss manuell die richtigen Einstellungen tätigen. Lässt sich sowas nicht auch über JobJackets steuern?

Ansonsten: Wenn es auch für Einsteiger modifiziert ist, könnte die Methode sicher Verbreitung finden, denke ich.

Hallo xpressio,

Antwort auf:

was so alles in Schulbaden rumliegt ;–)

Du würdest dich wundern ;)

Danke für den Gegenlesen. Wo offensichtliche Fehler sind werde ich das heute abend korrigieren. Ich werde auch versuchen, einige Sachen für Einsteiger besser verständlich zu machen, Du hast ja da auch einiges schon mal formuliert.

Antwort auf:

Die Profile für den Farbraum *Grau* können ja mitgeliefert werden, um den Usern die Erstellung zu ersparen.

Darüber habe ich nachgedacht, jedoch wieder verworfen: Da ich die Profile selbst mit Photoshop erstelle möchte ich keine Garantie dafür übernehmen. Es ist eben kein Standard. Ich werde die Anleitung aber nochmals besser mit einbinden.

Antwort auf:

Bei Erstellung eines neuen Dokuments auf Basis eines anderen JobJackets wird ein Regelverstoß angezeigt, weil die Voreinstellungen damit nicht übereinstimmen. D.h., man muss manuell die richtigen Einstellungen tätigen. Lässt sich sowas nicht auch über JobJackets steuern?

Doch, aber es geht leider nicht. Das hängt mit dem defaultjacket.xml zusammen. Ich habe das im "Probleme"-Dokument beschrieben und wie man das umgehen kann. Es ist momentan schlichtweg ein Bug.

Georg Obermayr

Hallo,

Antwort auf [ xpressio ]

Da die verwendeten Profile in den JobJackets nicht enthalten sind, wendet sich diese Anleitung an fortgeschrittene User. Für Einsteiger muss auch die Beschaffung und Speicherung der Profile beschrieben sein.

man muss doch kein fortgeschrittener XPress-User sein, um www.eci.org in einen Browser einzugeben und dann den Profile-Ordner zu finden. Wer das nicht hinbekommt, sollte erst recht die Finger von Profi-Software wie Xpress lassen.

Antwort auf:

Die Profile für den Farbraum *Grau* können ja mitgeliefert werden, um den Usern die Erstellung zu ersparen.

Nein können sie nicht. Die Verbreitung der Profile und deren Teilen, was "Schwarze Druckfarbe - Profil xy" ist, geschieht ausschließlich über die Website der ECI und das ist auch gut so, damit man auf jeden Fall die korrekten Profile und nicht namensgleichen Schund bekommt (was nicht heißen soll, dass Herr Obermayr Schund verbreiten würde, es ist grundsätzlich sinnvoll)

Antwort auf:

Ein Hinweis darauf, dass es sich ausschließlich um Print-Profile handelt, sollte auch nicht fehlen.

Dass das keine Scannerprofile sind, ist wohl selbstverständlich, oder?