Ich habe über den PDF-Export in IDCS (PC) eine PDF-X3 erzeugt. Der Acrobat-X3-Preflight zeigt keine Probleme an. Die Überdruckenvorschau ist ebenfalls ok. Aber bei der Druckplattenerstellung (CTP) in der Druckerei wurde im Schnittbereich mit dem Bildrahmen die Schrift "fetter" dargestellt. Wenn ich in Acrobat 6.03 mit dem Werkzeug "Bildauswahl" die Grafik, die in Indesign mit einem Schatten versehen wurde, anklicke, stelle ich fest, dass die Schrift genau in diesem Bereich betroffen ist (siehe Screenshot unter http://www.klartext-weinert.de/...oblem/screenshot.jpg 100 kB)
Ich vermute, dass die Überdrucken-Einstellungen in der Druckerei nicht korrekt sind, denn in der Vorschau ist alles okay.
Die Original-Pdf-Datei steht unter http://www.klartext-weinert.de/...ckplattenausgabe.pdf zur Verfügung (3,2MB).
Meine Fragen:
Handelt es sich um einen Fehler im PDF oder ist es ein Ausgabeproblem bei der Druckplattenerstellung?
Wie kann man den Fehler zukünftig vermeiden?

Hallo und welcome auf hds,

ich denke, dass da jemand das PDF getrappt hat, der nicht wusste was er tut.

Ich würde mal die Druckerei fragen, ob und wie getrappt wurde.

hallo wolfgang,

soviel ich feststellen konnte, ist das keinesfalls ein problem der druckerei/vorstufe sondern eine automatische umwandlung der schrift in zeichenwege (transparenzreduzierung) und zwar genau dort, wo die schrift auf den bildrahmen trifft.
event. zu beheben durch positionierung des textes über dem bild.

gruß patz

hallo wolfgang

um die antwort von loethelm noch etwas zu vertiefen:

die übliche trap-methode bei bild-vektor-übergängen ist, dass der trap-wert zur hälfte dem bild und zur hälfte dem vektor angerechnet wird. beispiel: wird ein auftrag mit 0.2pt getrappt, wird an dieser stelle der vektor und das bild um jeweils 0.1pt "fetter".

grenzt vektor an vektor, so wird densitometrisch entschieden, welcher der beiden vektoren um die vollen 0.2pt "gefettet" wird (jener mit der niedrigeren dichte). da aber ein bild von pixel zu pixel andere dichtewerte aufweisen kann, würde bei gleicher methode - welche technologisch durchaus machbar ist - eine möglicherweise sehr unschöne, gezackte überfüllung entstehen, die zwischen vektor und bild hin und herhüpft.

Zunächst einmal vielen Dank für die schnellen Antworten.

@ Loethelm:

Die Druckerei kann mir im Moment keine weiteren Infos zu den Trapping-Einstellungen geben und hat mich auf nächste Woche vertröstet. Sobald ich etwas erfahre, werde ich die Infos hier posten.


@ Patz:

ist die Schrift denn wirklich vektorisiert? Die Schrift lässt sich doch im PDF mit dem Textwerkzeug auswählen!?

Hallo Herr Weinert,

das Problem hatten wir doch hier oder in einem der anderen einschlägigen Foren bereits geklärt!
Das hat nicht mit Trapping/Überfüllung zu tun, sondern mit dem Einsatz von transparenz und einer stattgefundenen Transparenzreduzierung im Schnittflächenbereich zwischen Text und Bild.

Dadurch, dass der Text nicht in den Vordergrund gestellt wurde (es gibt also Seitenobjekte die weiter vorne liegen und mit transparenz versehen sind), wurde er mit verflacht. Aufgrund entweder falscher Transparenzreduzerungseinstellungen, zu geringer Ausgabeauflösung oder einer inkompatibilität des verarbeitenden PostScript-Interpreters kommt es nun zu diesem Verfettungseffekt. In diesem konkreten Fall kann ich falsche Verflachungseinstellungen als ursache ausschließen, weil Ihre PDF-Datei auf einem PostScript 3 RIP mit 2400 dpi ausgegeben zu einem perfekten Belichtungsergebnis führt. Also entweder ist die Auflösung zu gering oder ein Clone-RIP zum Einsatz.

Hallo Herr Zacherl,

Danke für den Beitrag. Meinen Sie mit Ausgabeauflösung die Einstellungen im PDF-Export von Indesign oder die Einstellung bei der Druckplattenausgabe?

Mit besten Grüßen

Wolfgang Weinert

Hallo Herr Weinert,

wenn es die Export-Einstellungen wären, dann würde das problem ja auch zu sehen sein, wenn ich die Datei auf ein anderes Ausgabegerät ausgebe. Da dies aber nicht der Fall ist (wie ich ja schon schrieb), meinte ich natürlich die Auflösung des Ausgabegeräts. Um diesen Effekt deutlich zu sehen musste dann aber mit weniger als 1200 dpi ausgegeben worden sein.

Aber die Auflösung ist eben nur eine von zwei (oder noch mehr) möglchen Ursachen. Ich würde intuitiv eher eine inkompatibilität des verarbeitenden RIPs als Ursache vermuten.

Hallo Herr Zacherl,

noch eine kurze Frage:

Ließe sich diese Fehlerausgabe zukünftig vermeiden, wenn im Indesign-Dokument der Text über der Grafik läge?

Mit besten Grüßen

Wolfgang Weinert

Hallo Herr Weinert,

die Frage läßt sich kurz und kapp mit "Ja" beantworten. Nicht-transparente Objekte die im Vordergrund liegen werden nicht verflacht außer Sie haben im Transparenzreduzierungsformat eingestellt dass der gesamte text in Zeichenwege gewandelt werden soll (was aber in dem von ihnen verwendeten Format nicht der Fall war).
Mich würde aber trotzdem sehr interessieren wie es zu dem Effekt kommen konnte. Können Sie herausbekommen welcher RIP beim Dienstleister zum Einsatz kommt und was mit der PDF-Datei vom Datenempfang bis zur Ausgabe auf dem RIP genau gemacht wurde?

Hallo,

fuer den hier zu eroerternden Textteil wurde beim Transparenzflachrechnen der Text beibehalten - aber als Beschneidungspfad. Dahinter liegt einfach ein 'Bild', das in diesem Fall komplett schwarz ist. Man sieht also das schwarze Bild nur innerhalb der Glyphumrisse der Schrift. Da es sich weiterhin um Schrift handelt, kann man sie auch mit dem Textselektionswerkzeug auswaehlen.

Robert Zacherls Vermutung im Prinzip koennte stimmen - moeglicherweise gibt es RIPs, die mit diesem Text-'Ausgabemodus' nicht einwandfrei zurechtkommen. Vielleicht wird aber auch irgendwo Trapping angewendet? Dann koennte ich mir auch vorstellen, dass der Trappingalgorithmus unterschiedliche Ergebnisse zeitigt, je nachdem, ob es sich um eine normale Schrift oder eine Schrift als Beschneidungspfad handelt (auch wenn beides visuell identisch ist/sein sollte).

Olaf Druemmer

Antwort auf:

... Vielleicht wird aber auch irgendwo Trapping angewendet? Dann koennte ich mir auch vorstellen, dass der Trappingalgorithmus unterschiedliche Ergebnisse zeitigt, je nachdem, ob es sich um eine normale Schrift oder eine Schrift als Beschneidungspfad handelt (auch wenn beides visuell identisch ist/sein sollte).

Hallo Olaf,

stimmt, daran hatte ich im Eifer des Gefechts gar nicht mehr daran gedacht. Ich denke aber weniger, dass der Auslöser eine Frage von echter Schrift oder nicht bzw. des Text Rendering Modes ist, sondern die Tatsache, dass der Text partiell auf Bilddaten liegt und viele objektoriente Trapping Algorithmen, wie auch das Adobe in-RIP Trapping, Bilder und damit in Berührung stehende Objekte anders behandeln als Vektordaten. Beim in-RIP Trapping von Adobe setzt man Bilder entweder pauschal auf Überfüllen, Unterfüllen oder eine zentrische Überfüllung.

D.h. uanbahängig davon, ob die Bilddaten heller oder dunkler sind als die damit in Berührung stehenden Objekte, werden entweder die Bilddaten ins Objekt hinein überfüllt, die Objekte ins Bild hinein überfüllt oder eine Kombination aus beidem (mit jeweils halber Trapping-Breite) eingesetzt.
Wenn der Text also im Bereich der Schnittfläche mit dem Bild verfettet aus dem Belichter kam, dann könnte bei den Trapping-Einstellungen der Bilder "Unterfüllen" oder "zentrische Überfüllung" aktiviert gewesen sein, was zu einer Vergrößerung des Textes in die Bilddaten hinein geführt hätte.
Es gibt zwar auch noch eine vierte Trapping-Option für Bilder die basierend auf der neutralen Dichte arbeitet (also so wie bei Vektordaten) diese ist aber sehr heikel, wenn rechteckige Bilddaten überfüllt werden, da es zu unruhigen Bildkanten kommen kann.

Solange wir natürlich nicht wissen, ob Trapping überhaupt zum Einsatz und ob es eine Technologie war die so arbeitet wie das IRT von Adobe, ist das alles wilde Spekulation.

Wie schon geschrieben, bin ich sehr gespannt was bei der Nachforschung herauskommt. Also welche Technologie und welcher Workflow beim Dienstleister zum Einsatz kam und was letztendlich der Auslöser des Problems war.