Guten Morgen Nice,

habe die Datei soeben durch unseren Workflow (Prinergy 3) geschickt und kann beim besten keinen Fehler entdecken.
Das bestätigt also das vorher gesagte, daß das RIP bei den Dienstleistern falsch konfiguriert wurde/ist.

Gruß emmes

Antwort auf [ rohrfrei ]

Wenn man sich mal diesen konkreten Fall ansieht, dann muß doch wohl die Frage erlaubt sein, warum man überhaupt so arbeitet. Da soll eine Sonderfarbe aufgerastert werden. Aber anstatt ein zweites Objekt aufzuziehen und das entsprechend einzufärben wird mit Transparenzen gearbeitet. Ok, wäre ja nicht so schlimm, wenn es nicht ausgerechnet "Weiß" wäre.

Und das stimmt ja noch nicht einmal. In InDesign heißt es explizit "Papier". Wie kann ich dann auf die Idee kommen, ein Objekt in Papier einzufärben und das auf transparent zu stellen?

Also diese Argumentation ist mir vollkommen unverständlich.
Da macht ein Dienstleister einen Fehler und hat offenkundig keine Ahnung (dazu später mehr) und das Ergebnis soll sein, dass man [Papier] nicht als Farbe akzeptiert??

Eine abgesoftete Fläche, die gleichzeitig über Text, Bild und Farbfläche geht kann nur so raelisiert werden. Und das muss und darf weiterhin erlaubt sein.

Hallo,

habe es ebenfalls mit Prinergy getestet und bin auch zu dem zu erwartenden Ergebnis gekommen:
Lässt man die Überdruckeneinstellungen von Weiß unverändert, kommt es wie gewünscht raus.
Eleminiert man die Überdruckeneinstellungen von Weiß, entsteht der Fehler.

Auch ein Indiz dafür, daß man sich auf die Überdruckenanzeige von Acrobat verlassen kann (was auch sonst?).

Zitat

Das bestätigt also das vorher gesagte, daß das RIP bei den Dienstleistern falsch konfiguriert wurde/ist.

Ich bin mir da einfach nicht so sicher wie Ihr. Wie viele Fehler wurden denn schon abgefangen, wenn man das überdruckenden Weiß korrigiert? Für mich wäre das nach wie vor die Standardeinstellung der letzten paar Jahre. Durch die Transparenzproblematik muß man hier neue Lösungen finden. Da finde ich es einfach viel zu platt, wenn man sagt, ich greife in überdruckendes weiß nicht mehr ein. Dadurch holt man sich dann wieder andere Fehler in's Haus. Und wer will dann sagen, daß die Daten so angeliefert wurden. Dann dreht doch der Datenlieferant den Spieß ganz einfach um und sagt: "Früher habt ihr das aber immer korrigiert, darauf habe ich mich verlassen.". Dann hast du das nächste Problem an der Backe.

Das RIP müsste irgendwie die Umstände erkennen können, warum das Weiß auf überdrucken steht. Ob da irgendwann mal eine Transparenz im Spiel war. Evtl. durch den Aufbau der Objekte oder so?

Da müssten sich mal die Hersteller ein paar mehr Gedanken machen, meine ich.

Gruß

Antwort auf [ Nice ]

Was die Kommunikation betrifft, habe ich im Vorfeld mit der Druckerei telefoniert und mir wurde gesagt, dass es völlig o.k. ist, wenn ich ein pdfx/3-konformes pdf liefere. Ich hatte auch nachgefragt ob ich wegen der Sonderfarbe oder dem Silber noch etwas beachten müsse und dies wurde verneint. Natürlich kann der Dienstleister nicht jede Eventualität berücksichtigen. Er hätte aber vielleicht auf eine Transparenz-Problematik verweisen können.

Wenn das tatsächlich so ist, dann hat die Druckerei nicht nur einen Fehler "im guten Glauben" gemacht. Damit meine ich, dass sie, weil es 15 Jahre lang notwendig war überdruckendes Weiß zu verändern, dies auch in deinem Fall gemacht hat.
Nein, die Druckerei hat eine Falschaussage gemacht. Denn Wenn sie tatsächlich PDF/X-3 konforme Systeme hätte, oder präziser gesagt, einen PDF/X-3 konformen Workflow, dann wäre der Fehler nicht passiert.
Ich würde die Kosten an deiner Stelle nicht übernehmen sondern statdessen mit dem Kunden zur Druckerei und unter Aufsicht einen Proof der Altona Test Suite erstellen lassen.
Dann zeigt sich, was die unter PDF/X-3 konform verstehen.

Hallo Christoph,

Zitat

Da macht ein Dienstleister einen Fehler und hat offenkundig keine Ahnung (dazu später mehr) und das Ergebnis soll sein, dass man [Papier] nicht als Farbe akzeptiert??

Weiß um etwas abzudecken ist ja ok. Hat man in XPress ja auch so gemacht. Warum dann nicht in InDesign? Da spricht ja nix gegen.
Aber Weiß in Verbindung mit Überdrucken ist doch das Problem. Und da finde ich die Bezeichnung von ID total logisch. Weiß=Papier. Wie soll Papier überdrucken? Das geht technisch nicht !

Gruß

hallo rohrfrei

Antwort auf [ rohrfrei ]

Und da finde ich die Bezeichnung von ID total logisch. Weiß=Papier. Wie soll Papier überdrucken? Das geht technisch nicht !

ich kann deine argumentation schlicht nicht begreifen. wieso hängst du dich an einem variablen begriff auf? adobe hat sich einfallen lassen, weiss als "papier" zu benennen. na und? eigentlich könnte man die farbe auch apfel anschreiben, ist doch egal - deswegen kämst du doch auch nicht auf die idee, sie zu essen... blödes beispiel, ich weiss ;-)
fact ist: diese farbe definiert sich mit farbraum deviceCMYK 0%C 0%M 0%Y 0%K (bitte keine spitzfindigkeiten an dieser stelle ;-)). dies ist die farbe - unabhängig davon, wie man sie bezeichnen will.

Antwort auf [ rohrfrei ]

Ich bin mir da einfach nicht so sicher wie Ihr. Wie viele Fehler wurden denn schon abgefangen, wenn man das überdruckenden Weiß korrigiert? Für mich wäre das nach wie vor die Standardeinstellung der letzten paar Jahre. Durch die Transparenzproblematik muß man hier neue Lösungen finden. Da finde ich es einfach viel zu platt, wenn man sagt, ich greife in überdruckendes weiß nicht mehr ein.

eine einstellung, die in diesem punkt pauschal etwas ändert, ist definitiv falsch. es ist genau dasselbe wie mit haarlinien - der entscheid, ob korrigiert werden muss oder nicht, kann kein automatismus fällen, sondern der mensch ist gefragt! nur er kann beurteilen, ob ein zustand in einer bestimmten situation richtig ist oder nicht, weil schlicht beides potenziell möglich ist.

Nö rohrfrei,
das ist in XPress unlogisch.
Denn dort ist Papier=weiß. Und wie jeder weiß *sic* sind die wenigsten Papiere weiß, sondern gräulich oder gelblich. Wenn ich wollte, könnte ich die Farbe [Papier] in ID so ändern, dass sie die Farbe des Bedruckstoffes darstellt. Und dann macht es auch Sinn einen Rahmen aufzuziehen, der papierfarben ist. Denn zumindest im Offsetdruck wird selten mit der Farbe Weiß gedruckt, so, wie es XPress suggeriert.

Hallo,

also ich will mich ga echt nicht drüber streiten mit euch. Wir haben offensichtlich andere Sichtweisen.

Gremlin sagt aber natürlich zu recht, daß es im PDF die Farbe "Weiß" auch nicht mehr gibt. Stimmt.

Also ziehe ich für mich den Schluß, daß ich mit der Bezeichnung von ID total gut leben kann, weil ich es logisch finde. Und wenn es an die Weiterverarbeitung des PDFs geht, muß man halt neu drüber nachdenken.

Und auch das Argument von Christioph ist eigentlich in sich total schlüssig. Da lasse ich mich gerne überzeugen, da habe ich überhaupt kein Problem mit.

Wenn man PDF/X-3 arbeiten will, dann konsequent. Und der Verweis auf die Altona hat mich auch überzeugt. Also kann das nur bedeuten, daß man die Überdruckeneinstellungen unangetastet lässt. Standardmässig.

Was man dann individuell macht über die verschiedenen Werkzeuge ist ja eine ganz andere Kanne Bier. Das ist dann der persönlichen Intelligenz oder Motivation überlassen.

Hat denn keiner mal Lust, den Distiller 6 und 7 gegeneinander zu testen? Ich meine die 0,1%.

Gruß

hallo rohrfrei

Antwort auf [ rohrfrei ]

Hat denn keiner mal Lust, den Distiller 6 und 7 gegeneinander zu testen? Ich meine die 0,1%.

dann schmeiss doch mal ein bisschen mehr facts in die runde. was hast du das genau gemacht? welche softwares/versionen sind beteiligtt? wie und wo wird geprüft? ...?

Antwort auf [ rohrfrei ]

Ich habe das jetzt auch mal nachgebaut und ein PS mit Distiller 6 und 7 zu PDF/X1a gewandelt.

Bei Distiller 6 hat die weiße Fläche mit Pitstop gemessen in allen Auszügen 0%.
Bei Distiller 7 hat die weiße Fläche mit Pitstop gemessen in schwarz 0,1%.

Demzufoge scheitert der Preflight-Check in Acrobat 7 auf überdruckendes weiß auch beim einen Dokument.

Könnte das mal bitte jemand gegenchecken?

Ich bin der Meinung, daß beide Distiller identisch konfiguriert sind, auch mit allen startups.

Hallo rohrfrei,

das ist von mir reproduzierbar. Allerdings hat das nicht ursächlich etwas mit der Acrobat Distiller-Konfiguration zu tun. Die Tatsache, dass in der in Acrobat Distiller 7 generierten PDF-Datei plötzlich 0.05% Schwarzanteil in dem CMYK-Weiß zu finden sind, ist auf den PostScript-Code von Adobe InDesign zurückzuführen. Hier der entsprechende Code-Ausschnitt:

Zitat

/setcmykcolor[
{
4 copy add add add 0 eq currentoverprint and{
pop 0.0005
}if
}/exec cvx
...
]cvx def

Übersetzt heißt dies, dass der "setcmykcolor" Operator so von Adobe InDesign umdefiniert wird, dass dieser prüft, ob alle 4 CMYK Farbkanal-Tonwerte aufsummiert 0 ergeben und gleichzeitig das Überdrucken aktiv ist. Wenn ja, dann wird der 0% Schwarz-Tonwert durch 0,05% ersetzt.
D.h. Adobe sorgt von sich aus dafür, dass kein reines, überdruckendes CMYK-Weiß entstehen kann. Auf diese Weise wird aber nur verhindert, dass ein im Hintergrund liegendes Schwarz versehentlich überdruckt wird.

Warum funktioniert das aber nicht bei dem PDF, welches im Distiller 6 generiert wird? Nun ganz einfach deshalb, weil die Rechengenauigkeit des Distiller 6 zu gering ist, und er die vierte Nachkommastelle des Schwarz-Tonwerts innerhalb der Farbdefinition "verschluckt".

Dummerweise ist die Separations- bzw. Ausgabevorschau und deren Densitometer-Tool auch zu ungenau, um diesen Tonwert anzuzeigen. Anscheinend zeigt ein Acrobat 7 Professional erst einen Tonwert von 0,59% als 1% (es werden leider nur ganzzahlige Prozentwerte angezeigt) an. Da bieten PitStop Professional und Heidelberg Prinect Color Editor eine wesentlich größere Präzision.
Auch die Überdruckenvorschau von Acrobat 7 reagiert erst ab 0,2% Tonwert wie erwartet. Das sind also klare KO-Kriterien für eine rein visuelle Datenprüfung. Hier muss mit präzisen Preflight-Werkzeugen geprüft werden. Die visuelle Prüfung ist allerdings ergänzend sinnvoll.

Und genauso ist auch mit Weiß überdrucken umzugehen. Das pauschale Aussparen von Weiß muss aus den RIP-Setups raus. Da gibt es keine Diskussion.
Stattdessen muss im Vorweg ein Preflight-Check auf Weiß überdrucken durchgeführt werden. Wohlgemerkt eine reine Prüfung - keine automatische Korrektur. Basierend auf dem Preflight-Ergebnis muss dann unter visueller Kontrolle entschieden werden, ob es im konkreten Fall sinnvoll ist oder nicht das Überdrucken-Attribut beizubehalten oder zu entfernen. Dies wird dann am PDF ausgeführt und dieses PDF wird dann von einem RIP verarbeitet, welches nicht mehr in Daten "reinpfuscht".

Übrigens liese sich dieses konkrete Problem leicht umgehen, wenn, wie wir immer wieder empfehlen, anstelle des "Composite-CMYK" Ausgabemodus von Adobe InDesign der "In-RIP Separationen" Ausgabemodus zum Einsatz gekommen wäre. Dann entsteht nämlich gar nicht erst diese weiße, überdruckende Fläche.

Hallo,

also da habe ich die letzten Stunden mal wieder wirklich was gelernt hier auf HDS. Gratulation an uns alle ;-).
Blöd nur für Nice, die die Kosten dafür zu tragen hat. Aber vielleicht kann sie ja mit dem einen oder anderen Argument aus dieser Diskussion bei der Druckerei nochmal nachverhandeln. Auf jeden Fall sollte eine Kostenteilung drin sein, wenn nicht mehr.

Gruß

Antwort auf [ rohrfrei ]

Blöd nur für Nice, die die Kosten dafür zu tragen hat.

Also ich hoffe doch sehr, dass mitlerweile klar ist, dass das nicht notwendig ist und dass Nice ausreichend Material hat, um sich bei Kunde und Druckerei durchzusetzen...

Antwort auf [ Christoph Steffens ]

Antwort auf [ rohrfrei ]

Blöd nur für Nice, die die Kosten dafür zu tragen hat.

Also ich hoffe doch sehr, dass mitlerweile klar ist, dass das nicht notwendig ist und dass Nice ausreichend Material hat, um sich bei Kunde und Druckerei durchzusetzen...

Erstmal: Die fachlich fundierte Diskussion und die gute Argumentation in beide Richtungen fand ich auch sehr interessant und auf jeden Fall lehrreich! Dafür vielen Dank an alle.

Nach allem was ich jetzt gelesen habe, ist die Voreinstellung des RIPs aber vermutlich auch in Bezug auf meine Daten sinnvoll. Wie schon erwähnt ist in der Originaldatei oben ein 4-farbiges Bild vorhanden über das der transparente Balken links läuft. Und in dem Bild ist weiße Schrift!!
Das würde doch bedeuten, dass das Weiß der Schrift ebenfalls überdruckt worden wäre, wenn die Einstellung des pdfs erhalten geblieben wäre. Richtig?

Viele Grüße
Nicole

hallo nicole

Antwort auf [ Nice ]

Das würde doch bedeuten, dass das Weiß der Schrift ebenfalls überdruckt worden wäre, wenn die Einstellung des pdfs erhalten geblieben wäre. Richtig?

nein. ich nehme ja nicht an, dass die schrift ein (falsches) überdruckattribut hatte?
überdruck definiert sich nicht über ein gesamtes pdf-dokument oder eine pdf-seite, sondern ist objektbezogen.

Hallo,

nicht unbedingt. Der Fehler würde nur entstehen wenn die Schrift weiß UND auf überdrucken stehen würde.

Normalerweise erhält ein manuell erstelltes grafisches Objekt in XPress oder InDesign ja nicht per se das Überdrucken-Attribut. Wenn es nur weiß wäre und NICHT auf überdrucken stehen würde (so wie es richtig wäre), dann hätte auch ein "falsch konfiguriertes" RIP den weißen Text nicht verändert.

Es gibt aber eine Stolperfalle. Wenn man erst den Text in schwarz schreibt und dann hinterher weiß umfärbt. Der schwarze Text bekommt dann automatisch das Überdrucken-Attribut verpasst. Das ist im Fall schwarz ja auch korrekt, da schwarzer Text fast immer auf überdrucken stehen sollte. Das blöde ist nur, wenn man die Farbe ändert, ändert sich nicht automatisch das Überdruckenverhalten, sondern es bleibt bei der Einstellung von schwarz.

So war es immer in XPress. Wie ID sich hier genau verhält, kann ich jetzt nicht 100%ig sagen. Aber das o.g. Verhalten ist wahrscheinlich der Hauptgrund dafür, daß in so vielen Layouts weiß auf überdrucken steht. Einfach eine Falle des Programms. Und das ist auch der Grund, warum es in der Vergangenheit standardmässig im RIP korrigiert wurde. Hat bisher ja auch immer Sinn gemacht, bis die Transparenzen kamen.

Gruß