Hallo Forum - hier also mal ein kleines Problem von mir:

- Datei um Kunden: PDF/X-3 aus Quark geschrieben
- Proof mit ColorGate ProofGate4 (von mir erstellt)
- Belichtung mit InDesign CS2 (OS X 10.4.7) auf einer DotMate 7500 (Harlequin Eclipse-Rip SP3)

So, nun das Problem: in der Drucksache wurden einige Zeilen in Graustufen, Helligkeit 100% (weiss) (auf einer 100% Magenta-Fläche) auf Überdruck gestellt. Diese müßten nach meiner Logik also verschwinden.

In Acrobat 7 Pro bleibt diese Zeile trotz Überdrucken-Vorschau sichtbar (erst nach Konvertierung [mit Farben Konvertieren] in CMYK verschwindet sie - so wie es sein soll. Im Proof verschwindet nichts (so hat es der Kunde frei gegeben). Bei der Überdrucken-Vorschau der eingefügten Datei in InDesign und bei der Belichtung verschwindet die Zeile.

Wie kann es zu so unterschiedlichen Sachverhalten kommen? Haben InDesign und Acrobat nicht die gleichen Libs, um Überdruck zu simulieren?

Ich möchte natürlich in Zukunft so etwas vermeiden - leider hat in diesem Fall auch niemand auf die Warnmeldung beim Preflight geachtet - trotzdem wäre eine konsistent "richtige" Darstellung einer "falschen" Einstellung wünschenswert.... :-)

Hat jemand eine Erklärung???

Danke

Jens

Hallo friedb

Per Definition kann ein DeviceGray eine DeviceCMYK nicht überdrucken. DeviceGray kann nur DeviceN überdrucken.

Die Ausgabevorschau von Acrobat arbeitet korrekt.

Konvertieren Sie die Farben, wird DeviceGray (je nach Einstellung) in DeviceCMYK gewandelt. DeviceCMYK kann DeviceCMYK überdrucken (wenn zusätzlich zum Überdrucken auch der Illustrator Überdruckmodus respektive OPM aktiviert ist). Zu diesem Thema finden sie in der Liste sicherlich einige Themen.

Dieses PDF dann wieder in einem Layoutprogramm zu platzieren und dort per onHost Separation (das nehme ich in diesem Fall an) auszugeben stellt, wie sie selbst gesehen haben, eine Gefahrenstelle dar. (Das von Ihnen geschilderte Verhalten müsste ich erst selbst nachstellen. Zu diesem Zweck bitte ich um Zusendung Ihrer PDF Datei).

Ich bin mir ziemlich sicher, dass Ihr Harlequin RIP PDF Dateien direkt per Hotfolder verarbeiten kann.

Auch ist folgende Ursache denkbar: Einige Rips (Interpreter) verfügen über Funktionen, um Überdruckendes DeviceGray nicht nach Separation Black oder DeviceCMYK wandeln. Dann erhalten sie den selben Effekt.

Hallo Herr Kleinheider,

dieser Umstand war mir so noch nicht bekant - vielen Dank erst mal für den netten Hinweis.

Die Ausgabe über das Layout-Programm wurde leider notwendig, da einige Elemente noch zu der PDF hinzugefügt werden mussten. Ich werde am Nachmittag noch einmal die direkte Ausgabe über das RIP beobachten und ggf. die Einstellungen am RIP prüfen.

Bis dann

Jens Friedberger

Antwort auf [ pkleinheider ]

Per Definition kann ein DeviceGray eine DeviceCMYK nicht überdrucken. DeviceGray kann nur DeviceN überdrucken.

Hallo Peter,

ich würde es anders formulieren. DeviceGray kann nur Farbkanäle überdrucken, die nicht die Namen der vier CMYK-Prozeßfarben Cyan, Magenta, Yellow oder Black tragen. Da ein DeviceN-Farbraum ja auch alleinig unter Verwendung einer oder mehrerer dieser vier CMYK-Kanäle aufgebaut sein kann (QuarkXPress 6/7 machen das z.B. im DeviceN-Ausgabemodus bei CMYK-Objekten), trifft die allgemeine Forumlierung, dass DeviceGray nur DeviceN überdrucken kann, so nicht zu. Außerdem muss diese Regel um den "Separation" Farbraum erweitert werden, für den aber natürlich auch gilt, dass er nur dann überdruckt wird, wenn die definitierte Farbe kein CMYK-Kanal ist.

Um allen Problemen aus dem Weg zu gehen, sollte auf DeviceGray verzichtet und stattdessen Separation Black zum Einsatz kommen.

Antwort auf [ Robert Zacherl ]

Um allen Problemen aus dem Weg zu gehen, sollte auf DeviceGray verzichtet und stattdessen Separation Black zum Einsatz kommen.

Hallo Herr Zacherl,
hätte unser Mitarbeiter der Meldung beim Preflight etwas Beachtung gegeben, wäre das sicherlich nicht das Problem gewesen.

Ich habe nun noch mal einige Tests gemacht:
- Ausgabe der PDF über Hotfolder: DeviceGray-Zeile bleibt erhalten und erscheint in der Belichtung

- Belichtung aus InDesign: Zeile ist weg (auch in der Überdrucken-Vorschau)

- Erzeugen einer PDF-X3 aus InDesign: Zeile verschwindet auch in Acrobat-Vorschau. Die DeviceGray-Zeile ist nunmehr DeviceN (0.00%Black).

Ich vermute also, dass InDesign intern das DeviceGray in DeviceN wandelt. Falls jemand für diese Vermutung eine Qulle in der Dokumentation liefern könnte, wäre ich sehr dankbar.

Für die Zukunft werde ich also erst alle (speziellen) Kontrollfelder (die leider bei diesen Kunden gewünscht sind) anbringen, eine neue PDF erzeugen und davon ein Proof zur Kundenkontrolle erstellen.

Danke für die Hilfe!!!

Thx

Jens

Hallo Jens,

ist ist bestens bekannt, dass Adobe und auch andere Software-Entwickler die Ausgabe eines Separation "Black" oder DeviceN-Farbraums mit Kolorant "Black" dem DeviceGray Farbraum vorziehen, da nur so ein gewolltes Überdrucken von grauen bzw. schwarzen Objekten gesichtert ist.

Hallo Robert

Antwort auf:

ich würde es anders formulieren. DeviceGray kann nur Farbkanäle überdrucken, die nicht die Namen der vier CMYK-Prozeßfarben Cyan, Magenta, Yellow oder Black tragen. Da ein DeviceN-Farbraum ja auch alleinig unter Verwendung einer oder mehrerer dieser vier CMYK-Kanäle aufgebaut sein kann (QuarkXPress 6/7 machen das z.B. im DeviceN-Ausgabemodus bei CMYK-Objekten), trifft die allgemeine Forumlierung, dass DeviceGray nur DeviceN überdrucken kann, so nicht zu. Außerdem muss diese Regel um den "Separation" Farbraum erweitert werden, für den aber natürlich auch gilt, dass er nur dann überdruckt wird, wenn die definitierte Farbe kein CMYK-Kanal ist.

Du hast natürlich recht. Ich wollte in der Antwort nicht zu technisch werden. Im Anbetracht der über XPress erzeugten CMYK aufgebauten DeviceN Farbäume ist das natürlich eine wichtige Information.

Antwort auf [ Robert Zacherl ]

Hallo Jens,

ist ist bestens bekannt, dass Adobe und auch andere Software-Entwickler die Ausgabe eines Separation "Black" oder DeviceN-Farbraums mit Kolorant "Black" dem DeviceGray Farbraum vorziehen, da nur so ein gewolltes Überdrucken von grauen bzw. schwarzen Objekten gesichtert ist.

Hallo Robert,

mir war dieser Sachverhalt (bis jetzt) noch nicht bekannt. Aber es zeigt mir nur, dass ich hier richtig aufgehoben bin :-)

Ist also die Ausgabe einer PDF über InDesign als problematisch anzusehen? Gibt es noch weitere Fallstricke?

Vielen Dank für die Hilfe

Jens Friedberger

Antwort auf [ friedb ]

Ist also die Ausgabe einer PDF über InDesign als problematisch anzusehen? Gibt es noch weitere Fallstricke?

Hallo Herr Friedberger,

mir ist nicht klar, wie Sie zu dieser Schlußfolgerung kommen.
Das was Adobe da macht, ist meiner Meinung nach das einzig Richtige. Der Grund warum es in Ihrem Fall zum Problem wurde ist ein fehlerhaftes Ausgangsdokument und das Versäumnis die platzierte bzw. weiterverarbeitete PDF-Datei einer eingehenden Datenprüfung zu unterziehen und dabei z.B. auf weisse, überdruckende Objekte hin zu prüfen (wobei das eingesetzte Preflight-Profil bzw. die eingesetzte Prüftechnologie natürlich die verschiedenen Möglichkeiten Weiß zu definieren unterstützen muß).

Hallo Herr Friedberg

Ich würde es nicht so drastisch formulieren wie Hr. Zacherl. Ich sehe es auch von Seiten des Kunden, der ein PDF bekommt, auf X3 prüft (oder in X3 konvertiert) und pooft, und letztendlich ist auf der Platte nicht das selbe wie auf dem Proof.

Das Überdrucken, bzw. das Ändern von Überdruckparametern bei der PDF Verarbeitung stellt die DruVo immer wieder vor neue Herausforderungen. Aus diesem Grund habe ich eine spezielle Prüfregel für Acrobat zusammengestellt, die viele problematischen Überdruckdefinitonen als Warnung anzeigt. So kann ein Vorstufenmitarbeiter von Problem zu Problem navigieren um zu sehen, ob an dem PDF was zu ändern ist oder nicht.

Hallo Peter,

aber an den Überdrucken-Einstellungen wird doch gar nichts geändert. Das Objekt war vorher als überdruckend definiert und ist es nachher auch noch. Das Einzige was sich geändert hat ist der Objektfarbraum, der von DeviceGray nach Separation oder DeviceN Black geändert wurde und somit ein Überdrucken ermöglichte.
Oder anders ausgedrückt: hätte diese Farbraumänderung nicht stattgefunden, hätten PDF-Erzeuger bzw. der Dienstleister Glück gehabt und der in den Daten steckende Fehler hätte sich nicht negativ ausgewirkt. So wurde das Überdrucken aber nun möglich und es wurde das reproduziert was laut Objekt-Attribut auch geschehen musste - eine weiße Fläche sollte übedrucken.

Hallo Herr Kleinheider, Hallo Herr Zacherl, Hallo Forum,

(ich dachte wir waren vorhin schon beim Du ... egal *grin )

mein letztes Posting möchte ich nicht als "Schlußfolgergung" verstanden haben - es ist und bleibt eine Frage - aus der sicherlich eine Schlußfolgerung werden kann... ;-)

Ich sehe es einfach mal so: Wir haben auf die Warnmeldung "Dort ist ein Weißes Objekt (wie auch immer Weiß angelegt ist) - welches auf "überdrucken" steht nicht angemessen reagiert. Ich bin davon ausgegangen, daß es bei "Überdruckenvorschau" an in Acrobat zu gleichen Ergebnissen wie bei der in InDesign importierten Datei (auch dort "Überdruckenvorschau" ein ) kommen sollte. Mir ist nie auch nur der Gedanke gekommen, daß beim Import bestimmte "Elemente" intern umgerechnet werden ... [anders kann ich den von mir nach Tests beschriebenen Effekt nicht erklären]. Hätte ich die PDF aus Quark belichtet, wäre ich über einen solchen Effekt nicht verwundert gewesen. So aber bin ich (noch immer) etwas verwundert über die Behandlung der PDF in InDesign - ohne Vorwarnung. Es ist sicherlich der einzig Richtige Weg den Adobe dort gegangen ist (aus Sicht der Überdrucken Stituation von grauen und schwarzen Objekten) - in diesem speziellen Fall hat die Wandlung von DeviceGray in DeviceCMYK aber in Verbindung mit der Untergrund-Fläche und dem Objekt überdrucken Atribut ungeahnte Folgen.

In der Zukunft werde ich sicherlich ein Besonderes Augenmerk auf "solche" Objekte haben - woher ich dies vorher wissen sollte (bis auf aus den vielen lobenswerten Beiträgen in den diversen Foren von Ihnen, Herr Zacherl) ist mir schleierhaft.

Egal - ein netter Exkurs und eine Erfahrung mehr *lol

Wie schön, dass es nette Mitmenschen gibt, die die komplette PDF Reference, Fifth Edition, Version 1.6 gelesen haben und aufsagen können.

Mit freundlichen Grüßen

Jens Friedberger

Ich darf übrigens im Forum mit "Du" angesprochen werden."

Hallo Robert

Für mich ist das Anschauungssache. Dieser Thread ließe sich unendlich fortsetzten. Ich würde das erstmals als "dumm gelaufen" einreihen. Würde man nun die Altona Technical in InDesign positionieren und so belichten, kämen die ersten Reihen vom technischen Standpunkt her "falsch" heraus. Was ist nun richtig?

Sagen wir mal so:

Würde das PDF direkt belichtet werden, so muss die visuelle Anmutung beibehalten werden. Eine Änderung des Farbraums ist nicht gestattet (= Altona Technical muss korekt ausgegeben werden)

Wird ein PDF in InDesign positioniert, muss man auf überdruckendes DeviceGray achten, da dieses sonst nach DeviceN (nur Schwarzkanal Black) geändert wird und das visuelle Erscheinungsbild ändert.

D.h. jedes PDF ist zu prüfen, bevor es weiter verwendet wird. Womit wir bei einem meiner Liebsthemen wären, ...... - aber das ist eine andere Geschichte ;-)

Antwort auf [ Robert Zacherl ]

Oder anders ausgedrückt: hätte diese Farbraumänderung nicht stattgefunden, hätten PDF-Erzeuger bzw. der Dienstleister Glück gehabt und der in den Daten steckende Fehler hätte sich nicht negativ ausgewirkt. So wurde das Überdrucken aber nun möglich und es wurde das reproduziert was laut Objekt-Attribut auch geschehen musste - eine weiße Fläche sollte übedrucken.

Hallo Herr Zacherl,
natürlich ist die Anlage eines weißen Objektes mit den Attribut "überdrucken" nicht sinnvoll. Es ist aber (ohne das mir heute zuteil gewordene) Wissen nicht für den Dateianlieferer, der evt. mit Überdruckenvorschau an in Acrobat die Datei "auf Sicht" prüft und auch noch in irgendwelchen Adobe Dokumenten beschrieben wird "in diesem Fall kann dort 1000x Überdrucken stehen - es tut es nicht" - eine Anwendung aus dieser Schmiede einen Zustand herbeiführt wo dies nicht mehr der Fall ist und das Objekt das tut was es tun soll und überdruckt.

Es ist - und dabei bleibe ich - nicht sofort klar verständlich wie und warum es zu dieser Fehlersituation gekommen ist - erklären Sie dass einen Kunden, der Seine Datei gewissenhaft nach X3 erstellt hat.

Wahrscheinlich hat der Kunde nicht einmal Hand an das Logo gelegt, sondern es nur als EPS in Quark importiert.

Warum an dieser Stelle mit zweierlei Maß gearbeitet und einmal die "besondere Situation" von DeviceGary und das andere Mal das "gewollte Überdrucken von grauen Objekten" gesichert wird finde ich nicht ohne weiteres verständlich - zumindest sollte in der Anwendungsdokumentation einmal darauf hingewiesen werden.

Mit freundlichen Grüßen

Jens Friedberger

Antwort auf [ pkleinheider ]

Für mich ist das Anschauungssache. Dieser Thread ließe sich unendlich fortsetzten. Ich würde das erstmals als "dumm gelaufen" einreihen. Würde man nun die Altona Technical in InDesign positionieren und so belichten, kämen die ersten Reihen vom technischen Standpunkt her "falsch" heraus. Was ist nun richtig?)

Von meiner Seite unterschrieben und für richtig befunden.

Vielen Dank für die mir zuteil gewordenen Hilfe - ich wollte keinen Disput verursachen.

Liebe Grüße

Jens Friedberger