ich bin neu in diesem Forum. Mein Anliegen ist, das im Folgenden beschriebene Problem zu verstehen. Für Unterstützung dabei wäre ich super dankbar:
ich habe aus Indesign (Mac OS X) für den Druck eines 6-Seiten-Zickzackfalz-Flyers ein PDF/X-3 exportiert, in der Ausgabevorschau von Acrobat Pro werden alle Inhalte (PSD-Bilder, Vektorgrafiken, Text) unter Nicht-DeviceCMYK angezeigt, jedoch bleibt unter DeviceCMYK alles ausgespart. Eigentlich sollte es doch genau umgekehrt sein?
Der Acrobat Preflight befindet die Datei für PDF/X-3 konform. Alle Bilder wurden nach CMYK gewandelt. Die PDF-Analyse zeigt unter „Liste Objekte, die ICC basiertes CMYK verwenden“: 157 Treffer auf 2 Seiten verwenden ICC-basiertes CMYK. (Die Erläuterung hierzu ist: Objekte verwenden ICC-basiertes CMYK. Dies kann zu unvorhersehbaren Farbveränderungen führen, wenn die PDF-Datei konvertiert oder ausgegeben wird. Sie können die ICC-Profile mit einer Korrektur entfernen.)
Müssen diese Profile entfernt werden? Die Druckerei wünscht ein PDF/X-3 mit dem Profil Coated FOGRA39.
Leider verstehe ich dieses Problem nicht, es ist wohl ein grundlegendes Verständnisproblem von geräteabhängigem und geräteunabhängigem CMYK bzw. wodurch und an welcher Stelle die störenden ICC-Profile in die Datei gelangen.
Ich habe mich bei der PDF-Erstellung an den Cleverprinting Empfehlungen + Erläuterungen orientiert, meine Einstellungen sind folgende:
PDF: PDF/X-3:2002, Acrobat 4 Farbkonvertierung: In Zielprofil konvertieren (Werte beibehalten) Ziel: Coated FOGRA39 (ISO 12647–2.2004) Name des Ausgabemethodenprofils: Coated FOGRA39 (ISO 12647–2.2004) Transparenzreduzierung: Hohe Auflösung, abweichende Einstellungen auf Druckbögen ausgewählt
Die Bilder wurden als RGB-Dateien (Adobe RGB (1998) und sRGB) platziert, es liegen Vektorgrafiken aus Indesign selbst und eine .AI Datei in CMYK ohne eingebettetes Profil vor.
Das ist wirklich ungünstig, deshalb, weil mit profilierten Objekten bei späterer Verarbeitung immer noch etwas geschehen kann (nicht zwangsläufig muß...), wenn unnütze (wenn es sich um dieselben handelt wie dem OutputIntent einer pdf/x-Datei...) Quellprofile enthalten sind.
Abhilfe in Deinem Fall: Exportiere ein PDF/x-1, das ist sowieso das, was die Druckerei lieber haben will. Ein gültiges x-1 ist gleichzeitig immer auch ein gültiges x-3-PDF, aber hier würden beim Export mit Konvertieren(Werte erhalten) keine Quellprofile mit eingebettet.
Wenn die wirklich ein x-3 anfordern, dann brauchst Du streng genommen auch nicht zu konvertieren beim Export, wenn und solange Du beispielsweise mit quellprofilierten RGB-Daten layoutest, wie Du ja schreibst, dann müssen diese möglicherweise unterschiedlichen RGB-Profile ja in der x-3-Datei enthalten sein, damit der Dienstleister/bzw dessen software weiß, von wo aus in den Output-Intent (der wäre in Deinem Beispiel dann FOGRA39, den die anfordern) - konvertiert werden soll. Aber bei einer Druckerei, die heute noch x-3 anfordert, würde ich mich auf korrekte Weiterverarbeitung nicht verlassen wollen, ich würde lieber die Druckerei, die so etwas anfordert abschaffen wollen, als überflüssige Quellprofile... ;-)
Noch mal zum Verständnis: Die wollen einen OI (= OutputIntent) FOGRA39 als Hinweis/Bestätigung, das alles unprofilierte dafür bereits gedacht/separiert ist und abweichend davon profiliertes noch dahin konvertiert werden soll, wenn auf gestrichenem Papier im Bogenoffset gedruckt werden soll. Ein OI ist quasi eine Notiz im PDF und nicht zu verwechseln mit notwendigen oder unnützen Quellprofilen im standardisierten PDF.
(Bei x-1 und x-3 erlauben beide Standards keine Transparenzen mehr - die sollen beim Export verflacht werden, in einem x-4 können native Transparenzen verbleiben, aber auch heute kann nicht jedes zur Belichtung benötigte RIP Transparenzen in jedem Fall korrekt verarbeiten, deshalb wollen die ein x-3, obwohl sie eigentlich ein x-1 wollen, das aber selber noch nicht verstanden haben, weil das alles so kompliziert ist... ;-))
siehe oben, wenn nun überflüssige Quellprofile enthalten sind (CMYK-Objekte mit identischem Quellprofil und Output-Intent, dann kann es im späteren workflow der Druckerei zu ungewollten Konvertierungen kommen, muß aber nicht, deshalb der Ratschlag im Preflight, diese zu entfernen...)
Habe ich helfen können?
Wenn nicht frag ruhig nach,
Gruß,
Ulrich
(Dieser Beitrag wurde von Ulrich Lüder am 9. Apr 2018, 13:32 geändert)
Der lange und eignetlich sinnlose Teil (nur fürs Verständnis):
Wenn du aus ID ein PDF/X-3 exportierst, dann wird im Reiter 'Ausgabe' im Abschnitt 'Farbe' der dritte Eintrag ausgegraut und zwar mit dem Vorgabewert Berücksichtigung der Profile: ZielProfil einschliessen
Und das führt zu dem von dir beobachtete Phänomen, das jedem Bild ein Profil angehängt wird, das eigentlich obsolet ist, und dadurch im Preflght sämtliche CMYK Bilder als 'nicht Device CMYK' (steht im Prinzip für 'profiliert' respektive für 'noch nicht mit dem Outputintent abgefrühstückt') bemängelt werden.
Ich musste es zweimal schreiben, weil mein Safari in letzter Zeit irgendwann beim Verfassen von Beiträgen das Tippen eines Returns als Befehl zum Auffrischen des Browserfensters interpretiert und alles futsch ist.
Nachtrag: Aus dieser hirnlosen, von Ulrich ja ausführlich dargelegten Misere, dass PDF/X-3 in seiner vollen Pracht eigentlich niemand will, sondern nur PDF/X-3 mit dem Funktionsumfang von PDF/X-1a (aber drei ist ja mehr als 1 und deswegen vvvvviiiieeeellll besser!), ist ja auch der in Foren immer wieder zu findende Hinweis entstanden, aus ID heraus noch keine PDF/X zu generieren, sondern dies erst im Nachhinein in Acrobat Pro zu erledigen. Gut, bei PDF/X-4 gibts noch andere Gründe dafür, aber die Entstehung dieser Empfehlung war aus meiner Erinnerung mal diese blödsinnige Doppelauszeichung mit Bildprofil und gleichlautendem OI beim direkten PDF/X-3 Export.
Vielen, vielen Dank für die ausführlichen und sehr hilfreichen Antworten! Ich verstehe es also nun folgendermaßen, dass der OutputIntent der PDF/X-Datei ausreicht, um ein druckfähiges Dokument zu erzeugen, durch die Einstellung in ID mit der Vorgabe „Berücksichtigung der Profile: Zielprofil einschliessen“ aber das gleiche CMYK Profil an die einzelnen quellprofilierten RGB-Bilder weitergegeben wird. Diese Doppelung führt im Preflight zu der Aussage, dass Objekte vorliegen, die ein eigenes Profil haben, das eigentlich das gleiche ist. Ich hoffe, ich verstehe es richtig.
Beeinflusst dieser Umstand somit das gesamte Dokument, so dass in der Ausgabevorschau von Acrobat nicht nur die Bilder als NichtDevice-CMYK erscheinen, sondern auch Text, in ID erstellte Vektorgrafiken und platzierte CMYK-Objekte aus Illustrator? Oder könnte es dafür andere Gründe geben?
Ich sehe ein, dass die Erstellung eines PDF/X-1 wohl die brauchbarste Methode ist, dieses Dilemma zu lösen.
Ein herzliches Danke nochmal für die detaillierten Begründungen! Beste Grüße, Jana
In meiner Testdatei sind auch die 100K und 100M Texte getagt.
Das könnte aber auch daran liegen, dass ich die in deinen Vorgaben implementierte Abweichung von Dokument- und Ausgabe-CMYK-Profil nachgestellt habe.
Korrektur: Nein, scheint immer der Fall zu sein. Ich hab jetzt noch diverse Versionen von Arbeitsfarbraum=OI und Transparenzverflachungsfarbmodellen durchprobiert: Es ist immer alles Nicht-DeviceCMYK.
es verhält sich bei mir wie bei Thomas: Alles wird (überflüssigerweise) nochmal mit dem Profil des OI getaggt beim vorgekauten x-3-Exportdialog, wenn damit dann Konvertieren(Werte erhalten)/Zielprofile einschließen ausgegraut eingestellt wird. Den Sinn verstehe ich nicht, aber vielleicht hatte sich Adobe tatsächlich mal was dabei gedacht und wir kommen nur nicht (mehr) drauf?
Hier bin ich mir nicht sicher, ob ich Dich richtig verstanden habe: wenn alles entsprechend diesem gemäß separiert wurde - wie bei einem x-1, dann ja. Bleiben allerdings noch RGB´s oder für coated profilierte Bilder für Druck auf uncoated gemäß einem solchen eventuellen OI - wie beim x-3 und x-4 möglich, dann werden zwingend entsprechende Quellprofile - egal ob CMYK oder RGB, nur diesmal eben abweichend vom OI - als Taggs/dem jeweiligen Objekt angehängt auch noch benötigt, weil eine endgültige Konvertierung in die Druckausgabebedingung (OI) noch stattfinden soll.
nach vollzogener Konvertierung von RGB in CMYK: ja
Gruß,
Ulrich
(Dieser Beitrag wurde von Ulrich Lüder am 9. Apr 2018, 17:08 geändert)
An dieser Stelle könntest Du auch noch etwas verbessern.
Die vielleicht bessere Wahl: [x] Abweichende Einstellungen auf Druckbögen ignorieren.
Damit stellst Du sicher, dass Dein gewähltes Transparenzreduzierungsverfahren auch auf allen Druckbögen angewendet wird. ***** Mit herzlichem Gruß, Uwe Laubender
vielen Dank für den Hinweis! Tatsächlich hatte ich diese Einstellung zur Transparenzreduzierung auch wie von Dir empfohlen ausgewählt, aber in meiner Beschreibung missverständlich festgehalten.
Bei meiner Fehlersuche hatte ich mit einem anderen Arbeitsfarbraum und OI ebenfalls das gleiche Ergebnis, hatte aber vergessen es zu erwähnen… Es ist sehr hilfreich zu erfahren, dass es sich das Szenario wie hier geschildert auch bei anderen Einstellungen wiederholt und auch die Texte etc. erfasst.
Ok, ich verstehe, die verknüpften Bilder mit vom Ziel abweichenden Profilen können also nicht ohne die Angabe ihrer Quellprofile farblich korrekt für den angedachten OI übersetzt werden. Dagegen wirkt es sich im vorliegenden Fall ungünstig aus, dass beim PDF-Export unter ‚Farbe‘ das Zielprofil den Objekten automatisch zugefügt wird und sich mit dem OI doppelt.
Nochmals herzlichsten Dank, Ulrich und Thomas, für die intensive Auseinandersetzung mit der Problematik und wertvolle Aufklärung!
nun habe ich durchaus den Eindruck, daß Du es richtig verstehst, trotz der vielen Worte zuvor :-)
hier sollte man für spätere Mitleser vielleicht doch noch einschränken, daß sich diese Bestätigung in diesem Zusammenhang lediglich auf colormanagement bezieht ;-)
Ein bischen peinlich ist, daß mir jetzt aus dem Stand beinahe so gar nicht mehr einfallen will, warum doppelte Quellprofile (doppelt weil via OI/Ausgabebedingung bereits abgehandelt) potenziell eine "Gefahrenquelle" sein können. Hier aber zum erweiterten Verständnis doch noch ein Versuch ein Beispiel zu kreieren:
Immer dann z.B., wenn in letzter Minute von einer Druckbedingung in eine andere konvertiert werden muß, weil sich vielleicht das Papier oder eben gleich das Verfahren/doch die finale Ausgabebedingung (Uncoated oder newspaper statt ursprünglich geplant coated) geändert hat, sind Monochrom-, Sekundär- und Tertiärfarben in ihrer Reinheit bedroht, am prominentesten ist wohl das Beispiel Text in reinem Schwarz, der sich durch ein jetzt nicht mehr güliges Quellprofil dann nach einer nicht gewollten Konvertierirung vierfarbig aufbauen würde.
In Zeiten, in denen mittlerweile aber immer mehr devicelink-Technologie einzug hält oder schon gehalten hat in die Handhabung ist das aber mittlerweile auch schon wieder minimiert als Risiko.
Nichtsdestotrotz aber gibt es auch immer wieder Situationen in denen laut Anforderung für FOGRA39 oder ISOcoatedv2 separiert/mit entsprechendem OI ausgestattet werden soll und dann aber doch noch in ein spezielles Papierprofil konvertiert wird (Heaven42 z.B.). Das "Durcheinander" zwischen FOGRA27, 39, ISOcoatedv2, ISOcoatedv2(300) und dann noch diverse basiccolor-Profile, die alle für ein und dasselbe Druckverfahren, nämlich Offset gestrichen gültig sind, tut noch ein übriges hinzu in dieser Hinsicht.
"FOGRA39" als Anforderung ist somit auch mindestens zweideutig, entweder ist jetzt speziell das namensgleiche Adobe-Profil damit gemeint oder eben doch ISOcoatedv2, dessen Separation auf den FOGRA39-Charakterisierungsdaten beruht. Ist der OI nun mit dem Adobe-Profil FOGRA39 bestückt, deren workflow aber standardmäßig auf ISOcoatedv2 abgestimmt, dann ist das Kind bei unnützen, "doppelten" Quellprofilen ohne devicelink-Verarbeitung schon in den Brunnen gefallen.
Gruß
Ulrich
(Dieser Beitrag wurde von Ulrich Lüder am 10. Apr 2018, 08:38 geändert)
Die Gefahr besteht darin, dass die PDF-Spezifikation es bei der Verarbeitung von PDF freistellt, eine Farbkonvertierung vom Quellprofil zum Zielprofil (in diesem Kontext qua OutputIntent-Profil) durchzuführen (oder eben nicht), wenn beide Profile identisch sind.
Dadurch erfolgt dann eben manchmal eine Re-Separation und manchmal nicht - was v.a. bei rein schwarzen Objekten, aber auch anderen mit Primär- oder Sekundärfarben eher unerwünscht ist.
Olaf -- Olaf Druemmer | Geschäftsführer callas software gmbh | www.callassoftware.com axaio software GmbH | www.axaio.com
Das wird letztlich irgendwo in der Software entschieden, in der Regel ohne dass der Anwender dies steuern kann.
Bei 'besseren' Systemen (vermutlich alle professionellen Workflowsystem/RIPs) wird wahrscheinlich die Farbkonvertierung übersprungen (weniger Risiko, spart Zeit, 'farbmetrisch' unnötig), bei 'einfacheren' Systemen (z.B. direkt in einem Betriebssystem wie macOS mit Quartz oder einfacheren Allzweck-PDF-Werkzeugen) wir alles nach Schema F abgearbeitet, und dann wird in diesem Kontext eben auch farbkonvertiert. Ich habe diesbezüglich allerdings kein gesichertes Wissen...
Olaf -- Olaf Druemmer | Geschäftsführer callas software gmbh | www.callassoftware.com axaio software GmbH | www.axaio.com
Hallo, kann es sein, dass beim X-3 Export aus Indesign immer die Profile von jedem Bild mit gesichert werden, unabhängig vom OI?
Ich habe da gerade einen Test mit einer Seite mit nur einem RGB Bild (proPhoto Profil) gemacht und festgestellt, dass bei:
Farbkonvertierung: In Zielprofil konvertieren (Werte beibehalten) Ziel: CMYK-Arbeitsfarbraum - ISO coated v2 300% (ECI) Name des Ausgabemethodenprofils: CMYK-Arbeitsfarbraum - ISO coated v2 300% (ECI)
für X-3 in Acrobat Pro DC "Device-CMYK einblenden" eine weisse Seite ergibt und "ICC-basiertes CMYK" das Bild zeigt, es aber für X-4, sowie X-1a genau andersrum ist.
Unabhängig von der Einstellung X-1a, X-3 bzw. X-4 sind alle anderen Export-Dialog-Einstellungen gleich.
(Dieser Beitrag wurde von chico11mbit am 10. Apr 2018, 12:05 geändert)
Bei noch nicht konvertierten oder anders als Oi vorliegend wäre das ja dann auch sinnig bei x-3 und x-4 Export. Weil das bei "Konvertieren" aber auch geschieht wurde dieser Thread gestartet, wenn ich mich recht entsinne?
;-)
Ulrich
(Dieser Beitrag wurde von Ulrich Lüder am 10. Apr 2018, 12:25 geändert)
Das ist ja auch das, was man bei Beigabe eines OI bei einem PDF/X erwarten würde:
Alles was bereits im OI ist kommt ohne eigenes Profil aus, ist somit DeviceCMYK.
Der Rest braucht weil er noch RGB oder sonstwas ist, eben ein Quellprofil, oder weil es noch nicht im OI-CMYK ist, weil dieser quasi nur als Interims-OI verwendet wird.
Das ist ja auch das, was man bei Beigabe eines OI bei einem PDF/X erwarten würde:
Alles was bereits im OI ist kommt ohne eigenes Profil aus, ist somit DeviceCMYK.
Der Rest braucht weil er noch RGB oder sonstwas ist, eben ein Quellprofil, oder weil es noch nicht im OI-CMYK ist, weil dieser quasi nur als Interims-OI verwendet wird.
Farbkonvertierung: In Zielprofil konvertieren (Werte beibehalten) Ziel: CMYK-Arbeitsfarbraum - ISO coated v2 300% (ECI) Name des Ausgabemethodenprofils: CMYK-Arbeitsfarbraum - ISO coated v2 300% (ECI)
X-1a & X-4: Bild ist im Preflight im Device CMYK-Farbraum X-3: Bild ist im "ICC-basierten Farbraum: "ISO coated v2 300% (ECI)"
Sollten die Bilder nicht auch bei X-3 im Device Farbraum im PDF eingebunden sein? Und falls nicht, warum sind sie es dann in X-1a und X-4 ?
Dann lies doch einfach den Thread nochmal von Anfang an und komplett.
Genau darum gehts doch hier schon die ganze Zeit. Der PDF/X-3 Export macht Kappes! Nicht grundsätzlich verkehrt, aber fehlerträchtig und inkonsistent, wenn man PDF/X-1a und -4 dazu nimmt.
Dann lies doch einfach den Thread nochmal von Anfang an und komplett.
Genau darum gehts doch hier schon die ganze Zeit. Der PDF/X-3 Export macht Kappes! Nicht grundsätzlich verkehrt, aber fehlerträchtig und inkonsistent, wenn man PDF/X-1a und -4 dazu nimmt.
Danke an Euch, jetzt habe ich es. ich habe beim ersten Lesen des Threads ein Verständnisproblem aufgebaut. Das habe ich wohl beim Lesen mit durchgeschleppt und bin immer wieder drüber gestolpert.
Merkhilfe für mich: Wer Lesen kann, ist klar im Vorteil.