Hallo,
scheint ja ein "heisses Eisen" zu sein, dass ich da gestriffen habe. Wenn ich
die bisherigen Beiträge richtig zusammenfasse tut es also PDFX-3:2002 keinen Abbruch
CMYK-Elemente mit dem korrekten Profil zu taggen, selbst wenn es dem OI entspricht. Bei
ungetaggten CMYK-Objekten und einem CMYK-Output Intent geht man also davon aus, das die
ungetaggten CMYK-Objekte bereits im OI vorliegen. Ausser evtl. ein wenig
Speicherplatzverschwendung schadet es also nicht CMYK-Objekte korrekt zu taggen. Dem
Empfänger einer PDF-X3:2002 Datei steht es frei die gelieferten Informationen zu
missachten.
Ich persönlich halte es für widersinnig wenn ein Standard wie PDF-X3:2002 aufgeweicht wird
zugunsten einiger "Anwender" die Ihre RI oder sogar ICC-Profile falsch setzen.
Bewust oder unbewust sollte dabei keine Rolle spielen. Das wäre doch ein herber Schlag ins
Gesicht aller ambitionierten und professionell vorgehenden Benutzer und Entwickler dieses
Standards, die sich alle Mühe geben sauber und korrekt zu arbeiten. Wenn eine ausgebende
Instanz der erstellenden Instanz misstraut und daraufhin ohne weitere Absprache die
mitgelieferten Profile und RI missachtet, sind die resultierenden Reklamationen und
Fehlausgaben ganz klar zu Lasten der ausgebenden Instanz zu rechnen. Andersherum gesehen:
Wenn die erstellende Instanz falsche oder fehlerhafte Profile bzw. RI liefert und die
Ausgabe daraufhin fehlerhaft erfolgt, ist wohl auch klar wer dafür verantwortlich ist. Ich
gebe zu, der zweite Fall ist in der Praxis schwieriger nachzuweisen und durchzusetzen. Den
Letzten beißen halt doch oft die Hunde. Aber das ändert nun mal doch nichts an den
Grundlagen, oder? PDF-X3 war doch angetreten einen "Blind Exchange" zu
ermöglichen!? Und da muss man sich doch wohl blind auf die Angaben verlassen können.
Misstrauen und freie Interpretation ohne Rücksprache sind hier fehl am Platze. Auf den
Ersteller oder "Verursacher" von Dokumenten kommt im PDF-X Workflow eine
besondere Verantwortung bzw. Sorgfaltspflicht zu. Schließlich erntet er auch die dicksten
Lorbeeren (Zeitersparnis, Einsparungen bei den Produktionskosten) wenn die
Weiterverabeitung reibungslos und fehlerfrei klappt.
Doch zurück zu meiner eigentlichen Frage: Darf ich die ECI-Verantwortlichen darum bitten
die CMYK-Bestandteile der Altona-Suite mit den korrekten ICC-Profilen zu taggen? Wenn es
nicht schadet, würde dies die Testformen aus meiner Sicht vollständiger und eindeutiger
machen.
Eigentlich wollte ich gar keine Grundsatzdiskussion auslösen, sondern einfach nur die
bestehende Testform ein klein wenig verbessern.
Mit freundlichem Gruß,
Dieter Bethke
-----Ursprüngliche Nachricht-----
Von: Dieter Dolezal [mailto:ddolezal@hirte.de]
Gesendet: Dienstag, 4. Februar 2003 07:33
An: eci(a)lists.transmedia.de
Betreff: [Eci] Re: [Eci] Re: [Eci] Re: [Eci] Altona_visual, Elemente
22+24, Profile für CMYK nicht getaggt
Hallo, Herr Homann,
Am Montag, 03.02.03, um 18:17 Uhr (Europe/Berlin) schrieb Jan-Peter
Homann:
Hallo Herr Bethke, Hallo Olaf
Würden einzelne CMYK-Elemente einer PDF/X-3 Datei getaggt sein, dann
müssten Sie nach meinem Verständnis bei der Ausgabe vom Eingebetteten
Profil und dem im Objekt hinterlegten Rendering-Intent in das Profil
des Output-Intents umgerechnet werden. Wenn ein CMYK-Element einer
PDF/X-3 Datei ohne Colormanagement gerippt und gerastert werden soll,
darf also kein Profil eingebettet sein.
In der Praxis kann dies zu recht diffizilen Problemen führen. Die
meisten Druckereien ignorieren bei gelieferten PDF-Dateien Profile die
in einzelnen CMYK-Elemente eingebettet sind. Da es insbesonders bei
Photoshop 5 und 5.5 sehr schnell passiert, daß fälschlicherweise
SWOP-Profile an druckfertige CMYK-Bilder angehängt werden, ist diese
Vorgehensweise in der Praxis zu 99,9% richtig.
Arbeitet man PDF/X-3 konform, so bedarf es bezüglich CMYK-Elementen
mit eingebetteten Profilen einer klaren Kommunikation zwischen
Druckerei und Datenlieferanten. Ich empfehle meinen Druckerei-Kunden
in ihren Richtlinien zur Datenanlieferung zu kommunizieren, daß
eingebette Profile in einzelnen CMYK-Elementen grundsätzlich ignoriert
werden, es sei den der Kunde weist in seinem Auftrag darauf hin, daß
diese Profile explizit berücksichtigt werden sollten.
Und genau da würde ich im Streitfall das Problem bei der Druckerei
sehen. Angenommen, eine Datenübergabe mittels PDF/X-3 ist vereinbart.
Wenn ich ein PDF/X-3 liefere, und ich möchte, dass meine Bilder genauso
wie im LWC gedruckt werden, obwohl das Objekt auf 125g Hochweiss PK1
läuft, und ich habe nicht nur meine Bilder mit einem korrekten PK3
Profil versehen, sondern auch den RI auf relativ gestellt, und der
Drucker ingoriert beim der Ausgabe die ICC-Profile, dann muss sich der
Drucker im Reklamationsfall darauf einstellen, dass er die Kosten
übernimmt.
Warum haben wir einen Standard, wenn einige Druckereien dann sagen: ist
gut, aber für uns gelten nur die Punkte 1-4, 6, 8 im Standard, der Rest
ist uns egal.
Dann landen wir erst recht wieder da, wo wir eigentlich nicht
hinwollten: Dass für jeden Datenversand das Datenformat auf den
Empfänger "gecustomized" ist. Da möchte ich mir die Frage erlauben:
Welcher Kunde bezahlt mir diesen Aufwand?????
Desweiteren sollte der Datenlieferant bei der
PDF/X-Erzeugung ein
Prüfprofil nutzen, welches RGB/Lab-Dateien und CMYK-Elemente mit
eingebettetem Profil als fehlerhaft markiert.
Mit dem PDF/X-3 Inspektor Freeware ist dies problemlos möglich. Bei
PitStop und InstantPDF muß man sich ein entsprechendes Prüfprofil erst
erstellen.
Streng genommen ist das Ignorieren von eingebetteten Profilen in
PDF/X-3 Dateien nicht Normkonform. Denkbar ist z.B. der Fall daß eine
solche PDF/X-3 Datei beim Datenlieferanten auf einem Proofsystem
ausgegeben wird, daß solche Profile korrekt berücksichtigt. Wenn die
Druckerei jetzt das die Profile in den einzelnen CMYK-Elementen nicht
berücksichtigt, kann sie evt. das Proof in der Auflage nicht > erreichen.
Lösungsvorschlag:
Die PDF/X-3 Community (ECI, FOGRA, bvdm ...) möge klar kommunizieren,
daß es Unterschiede zwischen 4cSpot-PDF/X-3 und ICC-PDF/X-3 gibt,
(ohne RGB/Lab und eingebette Profile bzw. alles erlaubt) und das diese
Unterscheidung für die Absprachen zwischen Datenlieferanten und
Druckerei von großer Beduetung sind.
Das ist, denke ich, der falsche Weg. Warum sollte man einen Standard
dadurch verwässern?
Jedem, der mit PDF/X-3 arbeitet, muß klar sein, dass bei der Einbettung
von Profilen in Bilder diese auch verwendet werden. Und passiert
irrtümlich der von Ihnen beschriebene Fehler - dann muss ich einfach
sagen, das ist Pech für den Lieferanten, denn er hätte dafür Sorge
tragen müssen, dass sein PDF/X-3 in Ordnung ist. Er hätte mittels
passenden Prüfprofilen sicherstellen können, dass in seiner PDF/X-3 nur
jene Profile an den CMYK-Bildern getaggt sind, die dem jeweiligen OI
des PDF/X-3 entsprechen - oder dass die CMYK -Bilder garnicht getaggt
sind.
Und man kann darüber hinaus einem Systemhersteller nicht zumuten,
zwischen PDF/X-3 und PDF/X-3 zu unterscheiden. Ihr Vorschlag mit
zusätzlicher Kommunikation würde dem Gedanken von PDF/X-3
zuwiderlaufen, dass es den "blind exchange" von Daten unterstützt. Das
kann nur passieren, wenn alle Parteien die richtige Sprache sprechen,
und das wiederum erfordert KEINE zusätzliche Kommunikation wie
"ignoriert aber bitte die eingebetteten Profile", sondern "Wenn ich
DeviceCMYK haben möchte, dann darf ich meine CMYK-Bilder nur mit dem
OI-Profil oder garnicht taggen". Und schon haben wir auch die von Ihnen
angesprochene Problematik mit den Prooflösungen nicht mehr.
Wir arbeiten seit 18 Monaten mit PDF/X-3 und ich kenne die von Ihnen
geschilderten Probleme nicht. Etwas mehr Sorgfalt auf Seiten des
Datenlieferanten, die Verwendung der (nicht mal teuren) Tools, und
schon hat man eine qualitativ hochwertige und sichere Prozessstrecke
etabliert.
Wenn darüber hinaus der Empfänger "sicherheitshalber" auch nochmals auf
die o.g. Punkte prüft, kann ich mir beim besten Willen keinen negativen
Effekt vorstellen.
Grüße aus der Hansestadt,
Dieter Dolezal
Würde diese Unterscheidung auch in Prooflösungen
integriert werden, so
könnte z.B. das Proofsystem bei aktivierten 4cSpot-PDF/X-3 Modus eine
Warnung ausgeben "Achtung die zu proofende Datei enthält RGB/Lab oder
ICCbased Elemente" was in vielen Fällen durchaus hilfreich sein würde.
Bei Interesse kann man auch unter
http://www.publish.de/data/hefte/pdf/ddpp200212/PP_2002_12_037.pdf
meinen Artikel aus der Publishing Praxis zu der Thematik nachlesen.
Grüße aus der Kastanienallee
Jan-Peter Homann
Olaf Drümmer schrieb:
Sehr geehrter Herr Bethke,
die CMYK-Bildelemente haben absichtlich kein ICC-Profil: sie sind fuer
die beabsichtigte Durckbedingung aufbereitet, und diese Druckbedingung
ist durch das ICC-Profil im OutputIntent - dem PDF/X spezifischen Teil
des PDFs - ausgewiesen. Daher besteht keine Notwendigkeit, diese
Elemente
mit einem CMYK-Profil zu versehen. Durch das
OutputIntent-Ausgabeprofil
haette man dennoch eine Moeglichkeit, bei Bedarf das PDf auf
kontrolierte
Weise in einen anderen Druckfarbraum umzurechnen.
Mit freundlichem Gruss,
Olaf
Dieter.Bethke(a)heidelberg.com wrote Fri, 31 Jan 2003 13:01:30 +0100
Hallo Liste,
ich habe die Vermutung, das die CMYK-Anteile der im Betreff genannten
Testelemente 22+24 der Altone_visual Testform nicht mit einem
getaggten
Profil versehen sind. Der RGB Anteil ist ja wie in der Dokumentation
beschrieben mit ECI-RGB getaggt. Ist meine Vermutung richtig, und
wenn ja
warum wurde auf das Taggen des CMYK-Profils verzichtet? Warum wurden
diese Elemente im PDF nur als "Form"-Object hinterlegt und sind somit
nicht für PitStop zugängig?
Mit freundlichen Grüßen / With kind regards,
Dieter Bethke
Heidelberger Druckmaschinen AG
Technical Group Digital Printing
Solution Center Digital (D-SM-SS)
Dr-Hell-Strasse
24107 Kiel
Germany
Telefon: +49-431-386-1685
Telefax: +49-431-386-1686
eMailto: support.digitalcolor(a)de.heidelberg.com
<mailto:support.digitalcolor@de.heidelberg.com>
_______________________________________________
Eci mailing list
Eci(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci
_______________________________________________
Eci mailing list
Eci(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci
--
-------------------------------------------------------
- Neue Adresse -
-------------------------------------------------------
colormanagement.de ---------- fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 -------
http://www.colormanagement.de
10435 Berlin --------- mailto:homann@colormanagement.de
_______________________________________________
Eci mailing list
Eci(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci
--
Hirte Medien-Service GmbH & Co. KG
Dieter Dolezal
Borsteler Chaussee 85-99a
Haus 17, Gewerbegebiet
22453 Hamburg
Voice: +49-(0)40-51497469
Fax: +49-(0)40-5118059
Mobile: +49-(0)177-5595276
route:
http://www.stadtplandienst.de/query;ORT=hh;LL=9.981616x53.607166;GR=2
_______________________________________________
Eci mailing list
Eci(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci