Hallo Forum,

wieder eine PDF-Frage, die ich bisher trotz Suche im Forum und Googeln nicht eindeutig klären konnte:
Ist überdruckendes Weiss in PDF/Xa1 bzw. X3 kein Fehler mehr?

Hintergrund ist der, dass nach der Konvertierung eines PDF1.6 (mit Transparenz und Text in Sonderfarbe) per pdfToolbox5 in ein gültiges PDF/X-1a (oder X3) plötzlich überdruckender, weißer Text auftaucht (OPM=0), der im Indesign CS5-Dokument nicht enthalten ist. Obwohl weiterer Text in der gleichen Sonderfarbe vorhanden ist, tauchen die "neuen" weiß-überdruckenden Texte nur dort auf, wo sich hinter dem Sonderfarb-Text eine weiße Fläche befindet, mal als Hintergrundfarbe des Textrahmens und mal als separate Hintergundfläche.
Generiert wird die (weiß-überdruckende) Kopie der entsprechenden SF-Textzeile jeweils nur bei X1 und X3-Konvertierung (nicht bei X4, da keine TP-Reduzierung), genauer gesagt also bei jeder Transparenzreduzierung MIT Farbkonvertierung in Verbindung mit Sonderfarbe UND weißem Hintergrund. Meine Mutmaßung, dass hierfür nur die "Konvertierungseinstellung" für "Schmuckfarbe(n)" innerhalb der pdfToolbox-Korrektur "Farben konvertieren" verantwortlich sein kann, konnte ich mit meinen bisherigen Tests leider nicht bestätigen.

Momentan verwende ich folgende Farbkonvertierungseinstellungen für X3 (am Beispiel ISOnewspaper)

Code

Farben konvertieren X3 (ISOnewspaper26v4) (DS) 
Kommentar: 
Ziel 
Farben konvertieren 
Ziel: ISOnewspaper26v4 
Zielprofil von OutputIntent verwenden, wenn vorhanden 
Einbettung: Als OutputIntent für PDF/X einbetten 
RGB: Adobe RGB (1998) 
CMYK: ISOnewspaper26v4 
Graustufen: Dot Gain 15% 
OutputIntent überschreibt angenommenes Profil 
Tiefenkompensierung verwenden 
Schwarze Objekte erhalten 
Erweiterte Konvertierungs-Richtlinie: Default.cfg 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Kalibriertes CMYK 
Konvertierung: Nicht konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Kalibriertes RGB 
Konvertierung: Nicht konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Kalibriertes Grau 
Konvertierung: Nicht konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Lab-Farbe 
Konvertierung: Nicht konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Unkalibriertes RGB 
Konvertierung: In Ziel konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Schmuckfarbe(n) 
Konvertierung: Nur Alternativ-Farbraum in Ziel konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 

...und folgende Farbkonvertierungseinstellungen für X1a (ebenfalls am Beispiel ISOnewspaper)

Code

Farben konvertieren X1 (ISOnewspaper26v4) (DS) 
Kommentar: 
Ziel 
Farben konvertieren 
Ziel: ISOnewspaper26v4 
Zielprofil von OutputIntent verwenden, wenn vorhanden 
Einbettung: Als OutputIntent für PDF/X einbetten 
RGB: Adobe RGB (1998) 
CMYK: ISOnewspaper26v4 
Graustufen: Dot Gain 15% 
OutputIntent überschreibt angenommenes Profil 
Tiefenkompensierung verwenden 
Schwarze Objekte erhalten 
Erweiterte Konvertierungs-Richtlinie: Default.cfg 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Kalibriertes CMYK 
Konvertierung: Dekalibrieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Kalibriertes RGB 
Konvertierung: In Ziel konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Kalibriertes Grau 
Konvertierung: Dekalibrieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Lab-Farbe 
Konvertierung: In Ziel konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Unkalibriertes RGB 
Konvertierung: In Ziel konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 
 
Konvertierungseinstellungen 
Farben konvertieren 
Objekte: Alle Objekte 
die verwenden: Schmuckfarbe(n) 
Konvertierung: Nur Alternativ-Farbraum in Ziel konvertieren 
Priorität (Rendering Intent): Rendering Intent von Dokument verwenden 

Könnt ihr hier einen Fehler entdecken?
...oder bin ich gezwungen, die (erst durch die X-Konvertierung enstehenden) weiß-überdruckenden Text aus dem nachgelagerten Preflight herauszunehmen (vor PDF/X-Konvertierung fand ebenfalls ein Preflight statt!)?

MfG

Nachtrag:
Da mir eine Reproduktion dieses Verhaltens mit anderen, gleichartigen Dateien partout nicht gelingen will, stelle ich hier das Vorher/Nachher-Problem-PDF, sowie ein pdfToolbox5-Konvertierungsprofil per Downloadlink bereit.
ftp://iftp_43312:NgJGCqkm@ftp.das-studio.de/Weiss_ueberdrucken.zip
Finden lassen sich die bei der PDF/Farbkonvertierung entstandenen, überdruckenden, weißen Texte (4 Treffer) mit jeder beliebigen Acrobat-Prüfung, welcher daraufhin prüft (sollte bei den meisten vorhanden sein).

Gruß

P.S.: Bin zwar erst wieder Mittwoch kommender Woche im Büro, verfolge aber von zuhause bzw. dem Urlaubsort etwaige Antworten und Tipps zur Fehleranalyse.

Hallo,

irgendwie habe ich permanent das Gefühl ein Deja-vue zu haben, wenn ich Deine Beiträge lese. Habe auch vor kurzem so einen Fall gehabt, der sich nicht erklären lässt. Zu Callas-Support geschickt und die Antwort bekommen, ist halt so und man könnte ja das resultierende PDF anschließend auf weiß-überdruckende Elemente kontrollieren mit einer zusäztlichen Regel. Ganz toll.

Ich habe noch mehr solche Kandidaten, die mich allmählich an der Toolbox (ver-)zweifeln lassen. Aber wenn ich die hier alle öffentlich stellen würde, dann würde mich Callas wahrscheinlich wegen Rufschädigung verklagen. Immerhin zeigen mir Deine Beiträge, dass es grundsätzlich nicht an mir oder meinen Kundendaten liegen kann. Ich habe für mich zumindest beschlossen, dass ich vorerst definitiv nicht in einen Callas-Toolbox-Server investieren werde, solange solche gravierenden und Daten-kaputtmachenden bugs in der Software existieren. Einen astreinen Fehldruck habe ich zumindest schon erzeugt, den nicht ich, sondern der Softwarehersteller zu verantworten hat :-((

Tut mir leid, dass ich dir nicht helfen kann. Evtl. sei nochmal der Hinweis auf diesen einen skurilen aber funktionierenden Workaround gegeben, dass PDF über eine Einstellung im Preflight-Profil als PDF 1.4 zu speichern. Aber vermutlich kollidiert das bei dir mit dem Wunsch ein X-1a zu erzeugen?

Gruß

Hallo "rohrfrei",

tut mir leid wenn ich Dir Descha-Wü's (sorry, frz. ist nicht meine Stärke ;-) bereite, was wohl wirklich daran liegen mag, dass wir vmtl. im selben Boot sitzen und uns vor oder beim Einsatz der pdfToolbox intensivst mit den tausenden Einstellmöglichkeiten befassen (müssen). Hierzu zieht man natürlich aktuelle Produktionsdaten und -PDFs heran. Dass diese wiederum meist nicht nach den Lehrbüchern erstellt sind, muss ich hier wohl nicht explizit erwähnen.

Trotz aller bisherigen Probleme scheint mir für unsere/meine Ansprüche derzeit kein Weg an der pdfToolbox vorbei zu gehen, denn vor allem im Zusammenspiel mit PowerSwitch und Scripting bietet dies ungeahnte Möglichkeiten. Leider stehe ich bereits kurz vor der Praxis-Testphase eines neuen PDF-Workflows, dessen Grundkonzept ein einziger Bug zunichte machen kann. In der Tat stolpere ich momentan oft über Probleme, welche ich selbst nicht lösen kann. Nach ettlichen Supportmails gesteht man einen Bug zwar ein, verweist aber z.T. auch auf die auf Acrobat-basierende Profil-Technologie und die dorther rührenden Programmfehler. So ist die Zuständigkeit für Fehler z.T. nicht klar, und einer verweist auf den anderen. pdfToolbox basiert auf Acrobat9 inkl. seiner noch offenen Bugs. Wendet man sich an Adobe verweist man auf Acrobat X. Ein offenes Geheimnis ist auch, dass die Druckvorstufe für Adobe lediglich eine Randgruppe ist und Bugfixes manchmal lange auf sich warten lassen (Ich denke da an die von Herrn Jaeggi seit Jahren penibel gelisteten Acrobat-Bugs, welche z.T. noch bis zur aktuellsten 9er Version ihr Unwesen treiben! Acrobat X steht mir noch nicht zur Verfügung - Fluch oder Segen?)

Jedenfalls stehe ich als "Endanwender" (einst reiner DTP'ler ohne weitere Kenntnisse über PDF, Acrobat-Prüfprofile, Scripting, etc. - aber schon immer mit Hang zu Workflow-Optimierungen) oftmals ziemlich alleine da mit meinen Problemen und poste meist erst nach vielen Stunden Try&Error hier im Forum:
"HDS, gut dass es Dich gibt!!!"
(Muss wieder mal gesagt werden und ich muss unbedingt meinen diesjährigen Obulus noch überweisen)

Zurück zum Thema: Noch tappe ich im Dunkeln, wer für die entstehenden Probleme (überdruckende Weißtexte) verantwortlich ist und ich schließe eine fehlerhafte Einstellung in meinen Settings keinesfalls aus. Doch auch Acrobat9 konvertiert zum gleichen, problematischen Ergebnis, so dass hier vielleicht wieder nur Warten hilft, auf ein neues Release – von wem auch immer. Leider habe ich diese Zeit nicht und muss handeln, sprich "Workarounden", sofern möglich.

Doch jetzt rufen andere Pflichten – Fortsetzung folgt; aber nach meinem freien Wochenende :o)

Antwort auf [ rohrfrei ]

Evtl. sei nochmal der Hinweis auf diesen einen skurilen aber funktionierenden Workaround gegeben, dass PDF über eine Einstellung im Preflight-Profil als PDF 1.4 zu speichern. Aber vermutlich kollidiert das bei dir mit dem Wunsch ein X-1a zu erzeugen?

Exakt, vielleicht ist jemand bereit, die seit Jahren existierenden PDF/X-Spezifiaktionen nachträglich nochmal an die neuen Bugs anzupassen?
War nur ein Scherz ;o)

Zitat

Trotz aller bisherigen Probleme scheint mir für unsere/meine Ansprüche derzeit kein Weg an der pdfToolbox vorbei zu gehen, denn vor allem im Zusammenspiel mit PowerSwitch und Scripting bietet dies ungeahnte Möglichkeiten.

genau das ist ja auch meine Denkweise und deshalb wollte ich das ja auch schon längst haben - aber lauffähig. Ich wollte neben meinem bestehenden Prinergy-Workflow für die Heavy-Metal-Abteilung (Offset) einen Parallel-Workflow mit Callas-Server und Switch aufbauen. Die Idee dahinter ist, dass ich für den Offset sowieso nicht am PDF-Workflow vorbeikomme, denn irgendwann muss ich mit den PDFs zwangsläufig auf den CtP-Belichter. Also wie bisher mit Prinergy. Das zeitaufwändige daran ist, dass man immer erst einen neuen Job eröffnen muss im Workflow (wenn das das MIS nicht schon erstellt hat), d.h. jede Farbkonvertierung oder PDF-Verarbeitung läuft nur durch einen vorher zu erstellenden job.

Mit einem Callas-Server evtl. in Kombination mit Switch ist das obsolet, denn da arbeiten die Hotfolder das ja ab. Aber nach meinen ersten Tests bin ich extrem ernüchtert, muss ich schon sagen. Ich habe zu Testzwecken immer mal wieder jobs parallel verarbeitet und dabei sehr (!) häufig festgestellt, dass PDFs aus der Callas-Toolbox suboptimal herausgekommen sind, die aus Prinergy absolut perfekt und normkonform waren. Tut mir leid, dass so sagen zu müssen. Ich hatte wie du, weiß-overprint-Probleme, wo keine sind, grau-overprint unvollständig, grau-farbkonvertierung fehlerhaft usw. Alles Probleme, die ich vorher in Prinergy überhaupt nicht kannte. Meine eigenen Preflight-Profile habe ihc nach Versions-Nr. durchnummeriert und bin mittlerweile bei Version 1.5 angekommen, was aber mehr als 5 Nachbesserungen bedeutet, da ich nur gravierende Änderungen neu nummeriert habe. Dabei habe ich auf meine bestehenden Profile aufgesetzt und immer nur wegen Software-bugs nachbessern müssen. Ich weiß, das hört sich arrogant und anmaßend an, aber ich versichere, dass es nicht durch Fehlbedienung entstanden ist. Irgendwann ist man dann halt mal frustriert und konkrete Aussagen vom Hersteller hört man über die offizielle Support-Hotline auch nicht mehr, seit dem das nach Belgien ausgelagert wurde. Es heißt immer nur "as soon as possible"...

Ich bin mittlerweile so weit, dass ich lieber für 20. oder 30.000 Euro mein Prinergy aufrüste, als 8.000 Euro in Automation-Server zu investieren. Ist das nicht bekloppt? Aber alles hat eine Ursache.

Ich will aber nicht unfair sein und grundsätzlich hast du mit Deinen Äußerungen auch nicht ganz unrecht bezgl. der Verantwortlichkeiten und dem Kompetenzgerangel. Das will ich aber eigentlicht nicht zu meinem Problem machen (lassen). Wenn ich gutes Geld dafür bezahle, dann soll das auch funktionieren. Und ich kann es nicht mehr hören, dass das bei Software eben so ist und nie perfekt sein kann. Komisch, besteht mein ABS, ESP und die Airbagsteuerung im Auto etwa aus mechanischen Zahnrädern? Das ist Software und die funktioniert sogar - es geht also wenn man will.

Gruß

Hallo Ihr zwei,

ich kann zu Euren Ausführungen nur nicken.
Statt Prinergy haben wir Prinect, dabei treten aber deutlich weniger Fehler auf, als bei callas oder enfocus.

Auf Prinect kann ich mich in 99,9 Prozent verlassen, während es bei callas geschätzte 99 Prozent sind. Das macht je nach Menge der Aufträge schon einen Unterschied.

Antwort auf [ t-kittel ]

...
Ist überdruckendes Weiss in PDF/Xa1 bzw. X3 kein Fehler mehr?
...

Überdruckendes Weiss war in PDF/X noch nie ein Fehler, und wird es dort auch nie sein.

Es gibt evtl. bestimmte empfohlene Prüfprofile, die überdruckendes Weiss anmeckern. Es gibt zugegebenermaßen auch mitunter gute Gründe, auf überdruckendes Weiss zu achten. In diesem Fall spielt allerdings eine große Rolle, dass überdruckendes CMYK-Weiss mit OPM=0 bedeutet, dass CMYK immer ausgespart wird, und lediglich Sonderfarben überdruckt werden würden. Enschlägige Prüfprofile wären gut beraten, wenn sie dieses Form von überdruckendem Weiss nicht anmeckern würden (das bekommt man aber den Organisationen, die entsprechende Empfehlungen ausgesprochen haben, mitunter nicht beigebogen - dort ist überdruckendes Weiss eben immer "böse").

Antwort auf [ t-kittel ]

Hintergrund ist der, dass nach der Konvertierung eines PDF1.6 (mit Transparenz und Text in Sonderfarbe) per pdfToolbox5 in ein gültiges PDF/X-1a (oder X3) plötzlich überdruckender, weißer Text auftaucht (OPM=0), der im Indesign CS5-Dokument nicht enthalten ist. Obwohl weiterer Text in der gleichen Sonderfarbe vorhanden ist, tauchen die "neuen" weiß-überdruckenden Texte nur dort auf, wo sich hinter dem Sonderfarb-Text eine weiße Fläche befindet, mal als Hintergrundfarbe des Textrahmens und mal als separate Hintergundfläche.

Ich habe mir die Daten angeschaut. Das Belichtungsergebnis wird absolut korrekt sein, da die überdruckende weisse Schrift lediglich CMYK ausspart (das ja aber sowieso weiss ist).

Man kann aus meiner Sicht also höchstens folgendes mit Fug und recht behaupten:
- das Ausgabeergebnis wird durch das Einfügen des überdruckenden weissen Textes zwischen Text in Sonderfarbe im Vordergrund und weisser Hintergrundfläche im Hintergrund nicht beeinträchtigt
- es werden der Seite Seitenobjekte hinzugefügt, die so vorher nicht vorhanden waren (nämlich besagte vier Textstücke in weisser Farbe, die die entsprechenden Tetstücke in Sonderfarbe unterlegen)

Diese Symptome gehen auf die Transparenzverflachung zurück, die für diese Seite durchgeführt wird. Die Transparenzverflachungsalgorithmen müssen auf viele Eventualitäten vorbereitet sein, insbesondere bei einem Zusammenspiel von Prozessfarben, Sonderfarben, Überdrucken (OP und OPM) und Transparenz (wobei letztere ja verflacht werden muss, die anderen Aspekte aber erhalten bleiben sollen).

In manchen Konstellationen muss man hierbei zu Maßnahmen greifen, die sich einem normalen Anwender wahrscheinlich nicht erschließen. Insbesondere werden oftmals weisse Objekte ins Spiel gebracht, die geeignet sind, bestimmte Farbkanäle auszusparen und andere nicht (in früheren Creative Suite-Versionen gab's dann bei einer Transparenzverflachung und anschließender Darstellung ohne Überdruckenvorschau bzw. Ausgabe auf nicht 100% PostScript/PDF-konformen/konform konfigurierten RIPs häufig weisse Rechtecke dor, wo Schlagschatten eingesetzt worden waren; in späteren Versionen wurden diese weissen Rechtecke 'weiter nach hinten' gelegt, es gibt entsprechende Probleme mit nicht-konformer Ausgabe/Darstellung da immer noch, aber die Effekte "hauen nicht mehr so ins Kontor").

Bezeichnend ist in diesem Kontext auch, wie richtigerweise berichtet wird, dass die überdruckenden weissen Texte ja nur vor weissem Hintegrund entstehen, woanders aber nicht. Das ist für mich ein Indikator, dass der Transparenzverflachungs-Algorithmus hier genau weiss was er tut (und sauber dafür sorgt, dass die eingefügten Objekte das Aussehen der Seite einwandfrei erhalten).

Ich bin mir nicht ganz sicher, warum nun in diesem Fall CMYK hinter den Sonderfarb-Textelemente ausmaskiert werden soll - es scheint mir im Grunde in dieser Beispieldatei überflüssig zu sein. Ich kann mir aber sehr ähnliche Seitenaufbauten vorstellen, bei denen eine weitere Sonderfarbe ins Spiel kommt, wo das dann sehr wohl Sinn macht.

Was bei dieser Seite auch noch interessant ist:
sie verwendet (unnötigerweise) eine Transparenzgruppe (für das blaue nach rechts zeigende Element), ohne dass aber innerhalb der Transparenzgruppe überhaupt Transparenz vorkäme. Dadurch wird dann im Grunde unnötigerweise eine Verflachung ausgeführt. Ich denke mal, dass das Nachstellen deswegen nicht geklappt hat, weil dieser eine Aspekt nicht mit nachgestellt wurde. Waurm die Transparenzgruppe überhaupt mit dem bauen Objekt auf der Seite gelandet ist, vermag ich nicht abzuschätzen (das kann höchstens der Ersteller eruieren...)

Ich würde für callas / die pdfToolbox aus dem Geschilderten eine Anregung mitnehmen:
-> wenn eine Transparenzgruppe vorhanden ist aber gar keine Transparenz verwendet wird, (optional) Transparenzgruppe entfernen oder Transparenzverflachung für die betreffende Seite nicht durchführen (außer es gibt woanders auf der Seite 'richtige' Transparenz).

Ich kann aus dem Stand nicht sagen, ob und wie schnell wir dies einbauen könn(t)en (es sind um diese Zeit schon alle daheim :-) ). Aber wir werden uns das näher anschauen/weiter überlegen.


Ich möchte insbesondere aber abschließend festhalten (soweit ich das an Hand der zur Verfügung gestellten Daten ersehen kann), dass zumindest auf dem Hintegrnd dieses Beispiels kein Bug in der pdfToolbox vorliegt, und dass daher aus unserer Sicht diesbeüglich auch nichts zu fixen wäre. Eine Transparenzverflachung muss ihrer Natur nach immer wieder bestimmte Kompromisse eingehen (es ist ja sicher bekannt, dass mitunter Objekte aufgerastert werden oder Schrift in Kurven gewandelt wird - alles nicht ideal, aber bei entsprechend komplexen Seiten unvermeidlich) - und hier ist es ein technischer "Kompromiss", der evtl. in diesem Einzelfall entbehrlich wäre, aber andererseits auch kein inkorrektes Ergebnis in der Darstellung oder Ausgabe erzeugt.


Olaf

Ich möchte in diesem Zusammenhang auch noch eine andere Fragestellung anstoßen:

warum werden PDF-Daten eigentlich nach PDF/X-1a oder PDF/X-3 verflacht, wenn man einen aktellen Prinergy oder Prinect Workflow/RIP sein eigen nennt? Warum wird nicht PDF/X-4 auf's RIP geschickt?

Olaf

Antwort auf [ olaflist ]

Ich möchte in diesem Zusammenhang auch noch eine andere Fragestellung anstoßen:

warum werden PDF-Daten eigentlich nach PDF/X-1a oder PDF/X-3 verflacht, wenn man einen aktellen Prinergy oder Prinect Workflow/RIP sein eigen nennt? Warum wird nicht PDF/X-4 auf's RIP geschickt?

Olaf

Hallo Herr Drümmer,

da gibt es eine einfache Begründung: bei einigen Transparenz-Konstellationen kann nicht überfüllt werden - weder vor dem RIP, noch mit InRIP-Trapping. Weder ein Harlequin-RIP, eine aktuelle APPE oder ein "aktueller" CPSI konnte an einigen Stellen überfüllen, solange Transparenz im Spiel war. Die verflachte Variante konnte dann sowohl vorher über das Prinect-eigene Trapmodul als auch mit allen InRIP-Trapping-Optionen korrekt überfüllt werden.

Das ist sicherlich nicht ideal, aber in einigen Fällen dennoch nötig. Gott sei Dank ist das aber eher die Ausnahme. Dann gibt es da noch einige "Fehler" (http://prinectuser.blogspot.com/...ltere-versionen.html) in der APPE und der pdflib von Adobe, die eine Transparenzreduzierung mit Acrobat 7 oder eine Ausgabe per CPSI nötig machen.

Im Großen und Ganzen werden hier aber PDFs mit Live-Transparenz (sei es ein PDF/X-4 oder nicht) an die APPE übergeben, die selten Probleme wie oben beschrieben verursachen. Wobei eine Transparenzverflachung in einem aktuellen Prinect-Workflow (siehe Link oben) ein Todesurteil für Druckdaten ist und der Erhalt der Transparenz (oder die externe Verflachung) praktisch gesehen die einzige Alternative ist.

Grüße,
Lars

Hallo,

Zitat von olaflist

Ich kann aus dem Stand nicht sagen, ob und wie schnell wir dies einbauen könn(t)en (es sind um diese Zeit schon alle daheim :-) ). Aber wir werden uns das näher anschauen/weiter überlegen.

Ich würde es begrüßen, wenn erstmal die vorhandenen offensichtlichen Fehler gefixt werden würden, bevor man sich an weitere Optimierungen macht.

Mein Problem mit "weiß überdrucken" ist nach näherer Betrachtung auch nicht mit diesem Fall vergleichbar. Ich hatte an Callas-Support ein DeviceCMYK-PDF reported, bei dem nach der Profilanwendung plötzlich zwei Textzeilen auf einer Seite das überdrucken-Attribut erhalten haben, wo vorher keines war. Folglich wurden die weißen CMYK-Textzeilen plötzlich unsichtbar. Der Fehler wurde vom Support bestätigt und mit einem Speicherüberlauf begründet. Ein Fix dessen erscheint mir weitaus wichtiger zu sein.

Zusätzlich hatte ich zwei Fälle, wo die Switchboard-Aktionen in der Callas-Toolbox Version 5 mit einer Fehlermeldung quittiert wurden, die in der Version 4 ohne Fehler erfolgreich bearbeitet wurden. Das war Sonderfarbenmapping und Ausschießen.

Gruß

Hello all,

als Urheber dieses Threads möchte ich mich hiermit vom verlängerten Wochenende zurückmelden und an dieser Stelle allen Beteiligten danken!

Da in meinem Fall weder Prinergy oder Prinect Workflow alternativ zur Verfügung stehen, möchte ich anhand der ausführlichen Erläuterungen von Hr. Drümmer nochmals auf das ursprüngliche Thena meiner Headline zurückkommen:

Antwort auf [ olaflist ]

Überdruckendes Weiss war in PDF/X noch nie ein Fehler, und wird es dort auch nie sein ... Es gibt zugegebenermaßen auch mitunter gute Gründe, auf überdruckendes Weiss zu achten ... Enschlägige Prüfprofile wären gut beraten, wenn sie dieses Form von überdruckendem Weiss nicht anmeckern würden ... dort ist überdruckendes Weiss eben immer "böse"

Dank Ihrer Erläuterungen habe ich nun erkannt, dass ich diesem "einschlägigen Irrtum" zum Opfer gefallen bin. Mit Ausnahme der mir bekannten "ungefährlichen" weiß-überdruckenden Schrift Courier als "Outline" der Seiteninformation einstiger (und aktueller?) QuarkXPress-PDFs, hielt ich in der Tat bisher alle anderen weiß-überdruckenden Elemente für fehlerhaft. Auch der von Ihnen beschriebene Unterschied von OPM 1 und OPM 0 (in Form Ihrer o.g. Definition) war mir in diesem Zusammenhang so nicht bewusst. - Doch genau hier sehe ich weiterhin das Problem, eine eindeutige, automatisierte Prüfregel anzulegen, welche jedem "normalen Anwender" sofort zeigt, ob hier ein Fehler vorliegt oder nicht (Stichwort "objektbezogene Pürfung", ohne Berücksichtung weiterer, dahinterliegender Elemente). Ich kann von einem DTP-Operator auch als fundierter Anwender gängiger Layoutprogramme nicht erwarten, dass er derart tiefgreifende Kenntnisse über PDF und dessen Transparenzreduzierung besitzt, und muss ihm aus eben diesen Gründen die Entscheidung über "gut" oder "böse" gänzlich abnehmen! Wäre denn - sofern der Acrobat-Preflight eine solche Unterscheidung zulässt (was ich erst in den kommenden Tagen testen kann) - eine generelle Interpretation von überdruckendem OPM 0-Weiß als "gut" und überdruckendes OPM1-Weiß = "böse" möglich?

Antwort auf [ olaflist ]

Man kann aus meiner Sicht also höchstens folgendes mit Fug und recht behaupten:
...
- es werden der Seite Seitenobjekte hinzugefügt, die so vorher nicht vorhanden waren (nämlich besagte vier Textstücke in weisser Farbe, die die entsprechenden Tetstücke in Sonderfarbe unterlegen)

Was ICH mit Hilfe Ihrer Erläuterungen zur Komplexität von Transparenzreduzierungen unter Rücksichtnahme auf alle Eventualitäten JETZT auch teilweise nachvollziehen kann. Würde ich jedoch weiterhin jegliches Weiß-Überdrucken in (der Transparenzreduzierung) nachgelagerten Preflights als Fehler werten lassen, würde wohl jeder "normale" DTP-Operator an sich zweifeln, da die bemängelten Objekte in seinem Layoutdokument definitiv nicht zu finden wären.

Antwort auf [ olaflist ]

...(in früheren Creative Suite-Versionen gab's dann bei einer Transparenzverflachung und anschließender Darstellung ohne Überdruckenvorschau bzw. Ausgabe auf nicht 100% PostScript/PDF-konformen/konform konfigurierten RIPs häufig weisse Rechtecke dor, wo Schlagschatten eingesetzt worden waren;...

Eine Erfahrung, die wohl 99% aller Druckvorstufler über lange Zeit hinweg leidvoll erfahren mussten. Dennoch bin ich mir sicher, dass nur ein Bruchteil der Betroffenen die hier und anderswo beschriebenen, detaillierten Hintergründe hierfür kennt! Von verärgerten Kunden am Telefon, welche anstelle von Schlagschatten nur weiße Flächen im PDF oder auf dem Laser- oder Farbausdruck sahen, ganz zu schweigen...

Antwort auf [ olaflist ]

Bezeichnend ist in diesem Kontext auch, wie richtigerweise berichtet wird, dass die überdruckenden weissen Texte ja nur vor weissem Hintegrund entstehen, woanders aber nicht. Das ist für mich ein Indikator, dass der Transparenzverflachungs-Algorithmus hier genau weiss was er tut (und sauber dafür sorgt, dass die eingefügten Objekte das Aussehen der Seite einwandfrei erhalten).

Was auch erklärt, dass es keinen Unterschied machte, wenn ich den weiß-eingefärbten Hintergrund des Textrahmens durch einen separaten, weißen Fond ersetzt hatte.

Antwort auf [ olaflist ]

Ich bin mir nicht ganz sicher, warum nun in diesem Fall CMYK hinter den Sonderfarb-Textelemente ausmaskiert werden soll - es scheint mir im Grunde in dieser Beispieldatei überflüssig zu sein. Ich kann mir aber sehr ähnliche Seitenaufbauten vorstellen, bei denen eine weitere Sonderfarbe ins Spiel kommt, wo das dann sehr wohl Sinn macht.

Solange es "nur" überflüssig ist und ohne Folgen bei der Ausgabe bleibt, werde ich mich nicht weiter daran stören. Womit ich mich mit meiner Frage nach einer "eindeutigen Prüfung" (OPM0=gut, OPM1=böse, siehe oben) nochmals bestätigt sehe.

Antwort auf [ olaflist ]

Was bei dieser Seite auch noch interessant ist:
sie verwendet (unnötigerweise) eine Transparenzgruppe (für das blaue nach rechts zeigende Element), ohne dass aber innerhalb der Transparenzgruppe überhaupt Transparenz vorkäme. Dadurch wird dann im Grunde unnötigerweise eine Verflachung ausgeführt. Ich denke mal, dass das Nachstellen deswegen nicht geklappt hat, weil dieser eine Aspekt nicht mit nachgestellt wurde. Waurm die Transparenzgruppe überhaupt mit dem bauen Objekt auf der Seite gelandet ist, vermag ich nicht abzuschätzen (das kann höchstens der Ersteller eruieren...)

Die Testdatei wurde von mir "auf die Schnelle entrümpelt", unnötige Elemente entfernt, um den Blick vom Wesentlichen nicht abzulenken. Dazu gehörte u.a. auch eine weiß-aussparende Textzeile direkt über dem angesprochenen blauen Element, welche aber selbst keine Transparenz enthielt (soweit ich mich erinnern kann). Hierzu müsste ich versuchen die Ursprungsdatei nochmals heranzuziehen, um zu klären, ob weitere Elemente mit "echter" Transparenz vorhanden waren. Unerklärlich hierbei für mich, dass trotz standgleichem Copy&Paste ALLER Seitenelemente auf eine neu-hinzugefügte Seite (im gleichen Dokument), die weiß-überdruckenden Texte (durch Transparenzred.) nur auf der Originalseite, nicht aber auf der Kopie generiert wurden.

Antwort auf [ olaflist ]

Ich würde für callas / die pdfToolbox aus dem Geschilderten eine Anregung mitnehmen:
-> wenn eine Transparenzgruppe vorhanden ist aber gar keine Transparenz verwendet wird, (optional) Transparenzgruppe entfernen...

Ein gut-gemeinter Rat, den ich in der Praxis für nicht zumutbar empfinde. Ein DTP-Operator, welcher (in unserer schnelllebigen Zeit) oft völlig Transparenzeffekt-überladene, z.T. satztechnisch total "vermurkste" Agenturdaten entgegennehmen, bereinigen bzw. reinzeichnen und bei Bedarf neu auf- und nachbauen, dabei noch "on-demand" auf Kundenwunsch Rechtschreibung und jedes einzelne Komma verantwortungsbewusst prüfen und evtl. korrigieren soll, dabei allerdings eine etwaige Verfälschung inhaltlicher Aussagen vermeiden muss, wird sich bei mir bedanken, wenn ich ihm erkläre, dass er zukünftig bitte den technischen Aufbau seines Layoutdokuments nicht nur dem nachfolgenden Strang des Workflows, sondern auch der darin eingesetzten Software anpassen soll. Hier sehe ich persönlich die Softwareentwickler in der Pflicht, "Benutzerfreundlichkeit" UND "Verständlichkeit" zu maximieren - wohlwissend, dass es hierbei um X3 mit Transparenzreduzierung, also ein komplexes Thema und noch dazu ein Auslaufmodell geht!
Wohl dem, der heute schon uneingeschränkt PDF/X4 und die APPE nutzen und stets direkten Kontakt zu seiner ""Haus&Hof-Druckerei" halten kann! In Anbetracht des vorherrschenden Zeitalters von Druckvermittlern (oft über fünf Ecken) und weltweitem, elektronischen PDF-Versand - häufig mit völliger Unkenntnis darüber, wer die HighRes-PDFs letztendlich, mit welcher Ausrüstung und Auflösung, irgendwo auf der Welt drucken wird - erscheinen mir persönlich die sicherlich gut-gemeinten Ratschläge zur intensiven und stetigen Kommunikation zwischen Vorstufenbetrieb und ausführender Druckerei eher als Farce.

Fazit: Kein Software-Bug, sondern "lediglich" Unwissenheit eines Anwenders, der eben nicht "hauptberuflich" pdfToolbox-Nutzer ist, sondern diese Software "nur" dazu einsetzen möchte, um Prozesse zu automatisieren und zu optimieren und dabei Kollegen davon profitieren zu lassen, die wenig oder keinerlei Kenntnisse von PDFs und deren Aufbau haben.

MfG
Thomas

Ich würde gerne aus dem inzwischen recht umfänglichen Thread zwei Punkte aufgreifen:

Zitat

Wäre denn - sofern der Acrobat-Preflight eine solche Unterscheidung zulässt (was ich erst in den kommenden Tagen testen kann) - eine generelle Interpretation von überdruckendem OPM 0-Weiß als "gut" und überdruckendes OPM1-Weiß = "böse" möglich?

In Preflight wie auch in pdfToolbox kann ich den "Illustrator overprint mode" abfragen (so wird OPM in UI-Sprache übersetzt), und damit entsprechende Checks bauen.

Weiss + DeviceCMYK + Overprint: ja + OPM: 1
-> ergibt Seitenojekte, die man nicht mehr sieht (außer man schaltet die Überdruckenvorschau aus, was in Acrobat zunehmend schwieriger wird); solche Objekte deuten auf 'verschwundene" Seitenteile hin und sollten nicht vorkommen

Weiss + DeviceCMYK + Overprint: ja + OPM: 0
-> sehe ich als unproblematisch an, und es kann in der Praxis (insbesondere nach Transparenzverflachung) vorkommen und sinnvol sein; drunterliegendes CMYK wird ausgespart (in korrekt arbeitenden RIPs...), man sieht das Weiss also, sofern es unten drunte rnicht schon weiss ist, oder ausschließlich Sonderfarbe drunterliegt


Checks auf "böses" überdruckendes Weiss:

[1 CMYK-Weiss]
DeviceCMYK: ja
Overprint:ja
OPM: 1

[2: nicht-CMYK-Weiss]
Objekt ist weiss
DeviceCMYK: nein
Overprint: Ja
[OPM ist egal, weil es nur bei DeviceCMYK zum Tragen kommen kann]

Zitat

Ein gut-gemeinter Rat, den ich in der Praxis für nicht zumutbar empfinde.

Der Rat war eigentich eher an uns/callas selbst gerichtet - die Software sollte auf Verflachung verzichten, wenn sie nicht erforderlich ist (weil zB zwar eine Transparenzgrupe vorliegt, aber nirgendwo darinnen tatsächlich Transparenz vorkommt) - da könnte eine nächste Version der pdToolbox differenzierter zu Werke gehen als bisher.


Olaf

Hallo Hr. Drümmer,

herzlichen Dank für die erneute Präzisierung des OPM-Themas, Ihre Geduld hier im Forum und Ihren ungebrochenen Willen, Ihr Produkt auf Anregung von uns Benutzern stetig weiter zu verbessern!
Außerdem freue ich mich immer, wenn ich (als "nicht ganz normaler" User) dazu beitragen kann, dem "ganz normalen " User die Welt ein wenig einfacher zu gestalten! :o)

MfG
Thomas Kittel

Fairerweise möchte ich erwähnen, dass ich von Callas mittlerweile die Rückinfo bekommen habe, dass die von mir reporteten Fehler im nächsten Update gefixt sein sollen. Das wäre schon mal gut.

Gruß