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:
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?
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.
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...
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.
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.
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.
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
als Antwort auf: [#482035]