Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03218.jsonl.gz/1290

EFI Fiery XF 6.4 und PDFX-ready Output test -> Bug?
Na ja - ich hatte den Eingangspost schon gelesen (wenn auch zugegebenermaßen eher flüchtig).
Wie dem auch sei: es hakt hier glaube ich an grundsätzlichen Fragen. Sobald ich in einer PDF-Datei, die Transparenzen verwendet (eigentlich genügt auch schon Überdrucken), anfange, Farben und Farbräume abzuändern oder umzurechnen, werden mir bestimmte Dinge um die Ohren fliegen (die Häufigkeit, mit der dies passiert, ist nicht unbedingt sehr hoch, im Einzelfall können die resultierenden Probleme aber sehr unangenehm sein) .
Beispiel Überdrucken:
Wenn ich eine Farbe zwecks Proofdarstellung oder was auch immer im PDF
umrechne, z.B. ein reines Cyan auf ein CMYK, bei dem ein oder mehrere Kanäle 'auf einmal' nicht mehr null sind, und Überdrucken mit OPM = 1 aktiv ist, werden manche Objekt-Kombinationen nicht mehr überdruckend erscheinen
Beispiel Transparenz:
12 der 16 Transparenz-Modi werden kanalweise (v)errechnet. Je nach Transparenz-Modus ist wichtig, wo (Vordergrund oder Hintergrund) der höhere Farbwert ist, oder wie die Farbwerte zwischen den Farbkanälen verteilt sind. Ändere ich hieran etwas (etwa weil ich eine Proofsimulation ins PDF rein-rechne), können regelrechte (mitunter drastische) Kipp-Effekte auftreten.
Mit anderen Worten: man kann eine PDF nicht immer (farblich) umformen, ohne dass einem ab und zu etwas um die Ohren fliegt. Egal ob für eine Prozessanpassung oder eine Proofsimulation. Die reine Lehre (ich weiss, nicht üblich und selten ohne weiteres realisierbar) würde verlangen, dass zunächst das 'ursprüngliche Ergebnis' qua PDF/X-4 ausgerechnet wird, und dann dieses Ergebnis (und nicht die vorher verarbeitete PDF-Datei), nachdem die Effekte der Transparenzen ermittelt worden sind, umgerechnet wird, z.B. als Umrechnung der in einem "Pixel-Buffer" vorliegenden Farbinformationen. Nach meinem Wissensstand können aktuelle RIPs das, ich habe aber keine Information darüber, ob die verfügbaren Workflow-Systeme das auch zugänglich machen.
Die diversen Hersteller von PDF-Verarbeitungswerkzeugen und -Workflows - auch wir von callas software - versuchen natürlich alles Erdenkliche, um "Unfälle" bei Farbkonvertierungen, Proofsimulationen & Co zu minimieren - ganz weg bekommt sie aber m.E. niemand (außer man rastert frühzeitig alles auf, was manche durchaus tun).
In einer idealen Welt würden immer nur perfekt aufbereitete, perfekt zum Ausgabeprozess passende PDF/X-4 erstellt und übermittelt werden, oder eintreffendes Material wird entsprechend aufbereitet, und anschließend
eine Druckfreigabe durch den Auftraggeber durchgeführt (hat es tatsächlich oder scheinbar farbliche oder sonstige Veränderungen durch die Aufbereitung gegeben, kann der Auftraggeber diese ablehnen - dann muss irgendjemand das gerade biegen - oder akzeptieren: in letzterem Fall ist man im grünen Bereich, und man druckt genau das, was der PDF/X-4-Standard verlangt, mit einem Ausgabesystem, was entsprechend idea konfiguriert ist).
Vielleicht auch noch zum mal weiter drüber Nachdenken: ohne PDF/X-4, und ohne Altona Test Suite 2, ist in vielen Fällen noch nicht einmal näherungsweise geschweige denn eindeutig definiert, wie denn das Ausgabeergebnis von PDF-Seiten mit Transparenz überhaupt aussehen muss! Ohne PDF/X-4 und Altona Test Suite 2 gibt es so viele Freiheitsgrade, dass fast jedes Ergebnis sich als korrekt bezeichnen könnte, ganz nach dem Motto "Wie hätten Sie's denn gerne - Scheitel links oder rechts, oder wie es fällt?"
Bunte Grüße aus Berlin!
Olaf
--
Olaf Druemmer | Geschäftsführer
callas software gmbh | www.callassoftware.com
axaio software GmbH | www.axaio.com
als Antwort auf: [#556153]