Herr Wendtland,

Zitat: "Es mag durchaus sein, das hier auch der Fehler in dem EPS lag.
FlightCheck hat die Sondefarbe jedoch sofort erkannt."

Dies deutet darauf hin, dass die Information wohl korrekt als DSC-Kommentare im EPS-Header (ode Trailer) hinterlegt war, aber der DSC-Parser im QuarkXPress EPS-Importfilter aus welchen Gründen auch immer, die Farbe nicht "gesehen" hat. Dies sagt aber nichts über die PostScript-Erzeugungsqualitäten eines Layout-Programms aus, sondern wirft höchstens ein schlechtes Licht auf dessen EPS-Importfilter.

Zitat: "Jedenfalls kann ich keine Sondefarbe separiert aus Xpress 4 herausgeben, wenn ich sie nicht in der Farbpalette habe."

Ist so auch nicht ganz korrekt. Es funktioniert zwar nicht bei der on-Host Separation aber sehr wohl bei der in-RIP Separation sofern die Sonderfarbe tatsächlich in der Composite-Datei enthalten ist. Ein Beispiel: Wenn Sie in QuarkXPress 4 oder 5 eine PDF mit enthaltenen Sonderfarben platzieren, tauchen diese nicht in der Farbpalette auf. Wenn ich nun on-Host aus QuarkXPress separiere erhalte ich tatsächlich nur die CMYK-Auszüge. Wenn ich dagegen die selbe Datei unsepariert auf den RIP schicke und dort die in-RIP Separation und die Ausgabe aller Sonderfarben erzwinge, dann erhalte ich die Sonderfarben aus dem platzierten PDF.

Zitat: "Ihr letzter Absatz hört sich so an, als ob die Grafikprogramme
(Freehand/Illustrator) bzw. RIPs für die Fehler verantwortlich sind,
die bei Separation aus XPress auftreten."

Da verstehen Sie mich miss. Schuld ist der Anwender des Layoutprogramms der versucht eine Separations-Technologie einzusetzen die über 20 jahre alt ist, die zu Zeiten von PostScript Level geschaffen wurde und sich seitdem nicht nennenswert weiterentwickelt hat und das zusammen mit modernen Produktionsdatenformaten wie PostScript Level 2 und PostScript 3 EPS-Dateien. Das kann auf Dauer nicht gut gehen.

Zitat: "... ich sehe es aber eher so, das Xpress eigentlich - wie andere Layoutprogramme - mit EPSen aus diesen Programmen umgehen können sollte (kann es nicht immer - ich weis).
Ist natürlich ziemlich blauäugig gesehen. Aber wir sind doch
jahrelang recht gut auch mit Level 2 EPS und Separationen gut
zurecht gekommen - irgentwie."

Es ist wirklich blauäugig (ist nicht böse gemeint), weil kein Layout-Programm dieser Welt ein beliebiges PostScript Level 2 oder PostScript 3 EPS korrekt separieren kann und es vermutlich auch nie können wird. Das fing schon vor Jahren mit JPEG-komprimierten Adobe Photoshop EPS-Bildern an und setzt sich heute in Form von EPS-Dateien fort die Konstrukte wie Smooth Shades in DeviceN-Farbräumen beinhalten.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Böc,

Sie dürfen nicht vergessen, dass es sich bei PDF im Gegensatz zu PostScript nicht um eine Programmiersprache, sondern um ein klar definiertes Datenformat handelt. Dies bringt z.B. mit sich, dass jede PDF-Datei dieser Welt, egal wie sie entstanden ist, eine einheitliche interne Struktur aufweist. Wenn dem nicht so wäre, würde die Datei von jedem PDF-verarbeitenden System als nicht konform zurückgewiesen werden.
Wenn Sie 10 PostScipt-Entwickler die simple Aufgabe stellen ein Programm per hand zu schreiben, das einen roten Kreis auf einem blauen Hintergrund malt, dann werden Sie 10 verschiedene Code abgeliefert bekommen, da jeder PostScript-Entwickler andere Vorstellungen von einem optimalen Code hat.
Wenn Sie 10 PDF-Entwicklern die selbe Aufgabe stellen, werden Sie 10 beinahe identische PDF-Dateien erhalten, da die Entwickler in einem engen Korsett stecken, das ihnen die Möglichkeit nimmt sich frei auszuleben.
Dies ist einer der großen Vorteile von PDF gegenüber PostScript.

Das es trotzdem gewisse inhaltliche Qualitätsunterschiede geben kann, das steht außer Zweifel. Hier ist aber z.B. ein AGFA Apogee Normalizer in keinster Wise einem korrekt konfigurierten Acrobat Distiller 4.0.5 oder neuer überlegen. Jeder der Ihnen das versucht weisszumachen, liegt falsch.
Die qualitativen Unterschiede zwischen einem JAWS PDF Creator 3 und einem Acrobat Distiller 4/5 sind (noch) vorhanden aber für die meisten Anwender absolut irrelevant.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

"...Es funktioniert zwar nicht bei der on-Host Separation..."
Wenn ich keine InRIP-Separation habe, heißt das für mich KEINE
Sonderfarbseparation aus XPress.

"Da verstehen Sie mich miss."
Nein - ich habe Sie schon richtig verstanden und gebe Ihnen in
fast allen Punkten recht. Ich sehe die Dinge nur eher aus der Perspektive eines "dummen" Anwenders. Ich weis schon, wo die Probleme liegen und bei welchen Dateien man aufpassen muß.

"Schuld ist der Anwender des Layoutprogramms der versucht eine Separations-Technologie einzusetzen die über 20 jahre alt ist"
Ha! Das Problem ist doch, das ihm keine andere Wahl bleibt!
Ich bekomme doch dauernd die Daten von Kunden die Ihre Drucksachen
selbst produzieren (und nicht wissen was sie tun).

"und das zusammen mit modernen Produktionsdatenformaten wie PostScript Level 2 und PostScript 3 EPS-Dateien. Das kann auf Dauer nicht gut gehen."
Leider geht es doch schon viel zu lange "gut". Wir produzieren
doch schon "ewig" mit Level 2 und 3 EPSen und XPress.
Es bleibt uns doch nichts anderes übrig, wenn wir "fertige"
Daten vom Kunden bekommen.
Das Problem ist die Fehler zu erkennen und zu verhindern.

"Es ist wirklich blauäugig (ist nicht böse gemeint)"
Hab ich auch nicht so verstanden ;-)
Wenn ich mich aber in unserer Abteilung umsehe und die Kundendaten
sehe: DIE sind blauäugig, weil kaum einer die richtige Ausbildung
oder Erfahrung hat. Machen Sie spasseshalber eine Umfrage zu
XPress 4 und PS-Level 2 und 3. kaum einer weiss, dass XPress
da Probleme hat (ok - andere Programme auch).
DAS meinte ich mit blauäugig.

Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Herr Wendtland,

Zitat: "Wenn ich keine InRIP-Separation habe, heißt das für mich KEINE
Sonderfarbseparation aus XPress."

Nein, das heißt es nicht zwangsläufig. Aber es heißt, dass Sie bei jedem Job auf's Neue befürchten müssen, dass das Separationsergebnis negativ ausfällt. Und das wird in Zukunft immer häufiger passier, je häufiger Anwender PDF-Dateien nativ im Layout-Programm platzieren oder eben EPS-Dateien aus PostScript 3 fähigen Illustrationsprogrammen.

Zitat: "Das Problem ist doch, das ihm keine andere Wahl bleibt!
Ich bekomme doch dauernd die Daten von Kunden die Ihre Drucksachen
selbst produzieren (und nicht wissen was sie tun)."

Sofern die Farbe in den Kundendaten noch korrekt ist (dies ist natürlich Voraussetzung für ein korrektes Separationsergebnis), ist der Einsatz der geteuerten in-RIP Separation in einem PostScript 3 RIP die Lösung aller Separationsprobleme. Wenn Ihr Workflow das nicht zuläßt, dann müssen Sie sich wohl oder übel mit dieser Separations-Problematik abfinden, denn es ist für eine Fa. Quark (und jede andere auch) unmöglich gewisse existierende technologische Grenzen zu sprengen.

Mit freundlichen Grüßen

Robert Zacherl

Kurz zusammengefasst:
Ich weis wo die Probleme beim sep. Workflow liegen und wie ich sie
löse. Bei "Problemfällen", wo ich angel. PDF separieren muß,
lese ich die PDF in InDesign ein und separieren von da aus
oder ich arbeite mit OPI.
Ich habe mich ja auch mit der Problematik abgefunden und irgentwie
arrangiert.

Beenden wir damit mal die wie immer fruchtbare Diskussion.
Was bleibt ist meine Frage nach den PS2 bzw. 3-Fähigkeiten
von XPress 6.

Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Herr Wendtland,

ok, Schluß damit.

Aber zwei kleine Anmerkungen noch:
Auch ein Adobe InDesign kann Ihnen niemals die Korrektheit einer on-Host separierten Datei garantieren (obwohl hier die Grenzen wesentlich höher anzusetzen sind als bei allen anderen Layout-Programmen. Dies hängt mit der zum Einsatz kommenden Technologie zusammen.)
Die PostScript level 2 bzw. PostScript 3 Fähigkeit eines Layout-Programms hat nichts mit dessen on-Host Separationsfähigkeit zu tun.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo, Herr Zacherl!

Ist nicht der Distiller in der Lage die onhost-separierten InDesign-PS-Dateien mit einem Kommentar oder einer Fehlermeldung auszugeben, wenn sich manche PostScript-Konstrukte NICHT separieren ließen? Ich glaube, daß ich bereits auf so einen Fall gestoßen bin.

Das Log des Distillers enthielt folgenden Kommentar: "(Warning: Job contains content that cannot be separated with on-host methods. This content appears on the black plate, and knocks out all other plates.)"

Leider wurde das NICHT vom InDesign beim Erstellen der PS-Datei gemeldet.

Gruß,

Uwe Laubender

Herr Laubender,

es ist richtig, dass Adobe InDesign einen Anwender vorsorglich während der PostScript-Verarbeitung per entsprechender RIP-Meldung warnt, wenn erkannt wird, dass PostScript Level 2 oder PostScript 3 Konstrukte in den on-Host separierten Daten enthalten sind. Das Erscheinen dieser Meldung heißt nicht zwangsweise, dass das Separationsergebnis falsch sein wird. Es ist nur ein Warnung, dass es so sein könnte.

Eine Warnmeldung bereits während der PostScript-Genererierung zu erzeugen ist aus technologischen Gründen kaum machbar. Wenn es zu dieser Meldung während der Ausgabe kommt, dann aufgrund von platzierten EPS-Dateien die Level 2 (oder noch neuere) Kontrukte beinhalten. Dies merkt aber nur der verarbeitende PostScript-Interpreter der Level 2 Farb-Operatoren antrifft. Adobe InDesign schleust aber beim Drucken, wie bereits mehrfach erwähnt, ja nur den platzierten PostScript-Code durch ohne ihn zu interpretieren (so wie es das Ausgabegerät tut). Somit kann es selbst gar nicht wissen ob ein Problem besteht oder nicht.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo nochmal alle zusammen,

die vorangegangene Diskussion, so aufschlußreich wie interessant sie auch ist, halte ich für sehr theoretisch und möchte deswegen dazu etwas sagen.
Ich höre auch von Kunden immer wieder dass Quark kein Level 2 wie 3 beherrscht. Im Zuge diese Diskussion über die Version 6 dieses Programmes spielt das doch für Produktionen nicht gerade die erste Geige. Gerade wenn mehrere Betriebe mit unterschiedlichem KnowHow und unterschiedlichen Möglichkeiten daran arbeiten. Lasst uns doch bitte einmal reel bleiben. Wichtig ist doch wie ein solches Produkt in einen Betrieb zu integrieren ist. Kann es ohne große Schulungen von den gleichen Leuten wie bisher verwendet werden und ist es möglich dieses Tool in einen Workflow zu integrieren. Alles was ich bis jetzt gesehen und gehört habe befürwortet diese Anforderungen.
Wie ich schon in vorangegangenen Postings erwänte ist eine konkrete Aussage derzeit eigentlich nicht wirklich möglich, denn selbst ich weis nicht mit voller Sicherheit ob nicht doch noch an der ein oder anderen Stelle gedreht wird. Ich gehe aber davon aus, dass eine L3 Anforderung in allen notwendigen Belangen umgesetzt werden kann und ich weis einfach, dass die eingekaufte Engine gut ist und was fast noch wichtiger ist, sehr oft eingesetzt wird, also folglich eine breite Basis von Erfahrung besitzt.
Ich bin auf Eure Antworten gespannt und hoffe keine Antwort vergessen zu haben, wenn doch sagt es mir bitte.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

ok, Schluß damit.

Hallo Conny,

anscheinend arbeiten Sie entweder selten oder gar nicht mit Sonderfarben und/oder setzen eben keinen composite Ausgabe-Workflow ein, sonst würden Sie die Situation sicherlich anders einschätzen.
Die Anzahl der Support-Anfragen die auf diese fehlende PostScript 3 Unterstützung zurückzuführen ist spricht jedenfalls eine eindeutige Sprache.
Ein typisches Beispiel ist brandaktuell in diesem Forum nachzulesen:
http://www.hilfdirselbst.ch/...24&topic_id=6789

Trotzdem ist keine Panikmache angesagt, weil es eben Lösungsstrategien gibt. Es ist nur schade, dass sich andere die Köpfe über solche Probleme zerbrechen müssen, nur weil ein Software-Entwickler jahrelang technologische Trends verschlafen hat.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo Robert,

dem möchte ich nicht gänzlich widersprechen. Ich produziere heute nicht mehr vorrangig mit XPress, kann da allerdings auf ca. 13 Jahre Erfahrung als Druckvorstufendienstleister zurückblicken und beschäftige mich eben die letzten beiden Jahre um den technik- bzw. den Prozess des Produzierens. Das soll nichts anderes heißen, als dass ich mich als Praktiker betrachte und als solche meine Workarounds entwickelt habe mit Problemen umzugehen. Ich neige nur einfach nicht dazu gleich das Kind mit dem Bad auszukippen, sondern eher nach einer Problemlösung zu suchen, die dem Problem gerecht wird. Sie scheinen im Gegensatz zu mir in diesem Thema PDF und composit Workflow wesentlich tiefer drinzustecken, was aber sicherlich nicht heißt, dass ich das entweder ignoriere oder um Probleme nicht weis. Auch in dem anderen von Ihnen erwähnten Thread habe ich eine Antwort gegeben die in diese Richtung geht. Ich habe bei Produktionen von Geschäftsausstattungen, die ja meißt auf Schmuckfarben basieren, bis jetzt keine Probleme gehabt.
Ich hoffe ich konnte meinen Standpunkt nun ein wenig klar machen. Gerne bin ich natürlich bereit mir weitere Grundlagen zu schaffen, wenn Sie mir da weitere fachverbindliche Informationen zukommen lassen wäre das sehr nett.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Conny,

ich hoffe Sie verstehen das jetzt nicht falsch. Ich schätze Ihre sehr fachlichen und fundierten Beiträge in diesem Forum sehr.
Ihre Aussage:

"... es kommt ein wenig auf die Version an um ein Bild richtig einzufärben, ich denke aber dass nicht in diesem Bereich Dein Problem liegt. Vielmehr denke ich, dass das Problem bei der Einrichtung der Schmuckfarbe liegt. Diese wird sicher nicht als Volltonfarbe angelegt sein und deswegen separiert."

zeigt aber ganz klar, dass selbst Sie sich aufgrund des nicht-Einsatzes eines composite Workflows offensichtlich auch nicht bewußt waren, dass KEINE heute verfügbare QuarkXPress Programmversion in der Lage ist ohne Einsatz einer entsprechenden XTension ein mit einer oder zwei Sonderfarbe(n) koloriertes Graustufen-TIFF korrekt unsepariert auszugeben.
Wenn Sie es mit 13 Jahren Programmerfahrung nicht wissen, wie sollte es dann der "normale" Quark-Anwender wissen?

Der von Ihnen propagierte Workaround ein Simplex/Duplex-Bild in Adobe Photoshop anzulegen funktioniert natürlich aber sagen Sie das mal einem Dienstleister der einen PDF-Workflow einsetzt und vom Kunden einen vermeintlich zweifarbigen, 48-seitigen Geschäftsbericht als PDF-Datei angeliefert bekommt und alle als Duplex gedachten Bilder plötzlich als CMYK-Bilder vorliegen.
Das heißt für den Dienstleister entweder alle Bilder in Photoshop zu konvertieren und neu zu verlinken (was neben dem Zeitaufwand auch eine potentielle Fehlerquelle darstellt) oder das PDF erneut mit geladener XTension erzeugen (wobei er erst die Daten von Kunden anfordern muss) oder die Vorzüge eines Composite Workflows über Bord zu werfen und einen für ihn absolut unattraktiven, weil nicht zu seinen Workflow-System passenden, vorseparierten Ausgabe-Workflow zu betreiben (und dabei Gefahr zu laufen, dass es wieder andere Probleme im Bereich der on-Host Separation gibt).

Man kann es drehen und wenden wie man will. Die Tatsache, dass Workarounds für die angesprochenen Defizite existieren ist schön und gut aber heißt nicht, dass die Probleme nicht mehr auftreten. Denn solange die QuarkXPress-Anwender zum größten Teil gar nicht um dessen Defizite wissen, werden sie weiterhin jedesmal ins offene Messer laufen. Und das müsste schon lange mehr passieren, wenn der Hersteller etwas früher aus seiner Lethargie erwacht wäre. Denn die dafür notwendige Technologie (PostScript 3 und die dazu passenden Ausgabegeräte) steht seit 1998 zur Verfügung.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo Robert,

leider muss ich aus Zeitgründen die Antwort, welche ich nicht schuldig bleiben möchte auf einen Späteren Zeitpunkt verschieben. Spätestens an Ostern werde ich mich hier noch einmal melden, danke aber dennoch für die fachliche Anerkennung und natürlich diskutiere ich immer wieder gerne und lasse mich auch ebenso gerne überzeugen, wenn ich Defizite in meinen Argumentationen haben sollte.
In diesem Sinne haben Sie bitte ein wenig Geduld - danke.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Nur wer als User folgende oder ähnliche Fragen jeweils ausführlich und abgewogen beantworten kann, kann in Zukunft in Ruhe leben, wenn er seine Daten zum Dienstleister (der viel mehr wissen muss) gibt:

Arbeiten wir mit PDF oder lieber mit offenen Dateien? Warum?

Ist mein Farbproof ein Composite- oder ein (an welcher Stelle?)Separiert-und-dann-wieder-zusammengesetztes-Proof?

Ist beim Farbproofing überfüllt worden?

Auf welchem Weg sind meine Sonderfarben beim Proofen simuliert worden?

Bei welchen Datenarten muss man immer noch zwingend separiert arbeiten?


Vielen Usern und Dienstleistern ist immer noch nicht klar, dass Layout-Dateien und darin enthaltene Bilddaten anders aufgebaut sein müssten oder sollten, wenn sie je nach gewähltem Ausgabe-Verfahren wirklich identische Druckergebnisse ergeben sollen.

Oder anders ausgedrückt: Unterschiedliche Verfahren führen bei gleichen Layoutdaten zu unterschiedlichen Druckergebnissen


Der momentane Technologie-Wechsel kann nur sehr gut ausgebildet überstanden werden, wenn man aber zu denen gehört, die schon seit Jahren "immer so" gearbeitet haben, wird noch so manch teure Überraschung erleben. Doch Achtung: Selbst auserwählte (man beachte die andere mögliche Sinnschöpfung) Technologie-Päpste empfehlen immer noch "grundsätzlich" die JPEG-Komprimierung in den Distiller-Einstellungen ...
Bis dann, bis zur nächsten Reklamation