Yo,
Antwort auf: leider sind Bernds und meine Fragen damit immer noch nicht beantwortet: Quark hat einen Workflow, der nicht up to date ist, das stört Dich. Uns stört es nicht, und unsere Weiterverarbeiter offensichtlich auch nicht.
Wie schon angedeutet eine Frage der "Perspektive". Mich interessieren die kreativen Möglichkeiten und die Perspektive des Dokument-Erstellers schlichtweg gar nicht. Mich interessiert, was in großen Workflows hinten rauskommt (das, was Quark da unter der Haube macht, wage ich nicht Workflow zu nennen, das ist ein Anachronismus).
Wenn man Xpress mit den Dateiformaten, wie sie vor 10 Jahren schon gebräuchlich waren (TIFF, EPS) nutzt, die eigenen Dokumente in keinen Workflows eine Rolle spielen und auch sowas wie Metadaten, die an Bildern kleben, keine Rolle spielen, dann ist das alles egal. Dann kann man prima mit den Möglichkeiten von XPress leben (vermute ich).
Die Situation hier ist halt 'ne andere: Wir machen in Workflow. Wir haben Kunden Lösungen gebaut, die dafür sorgen, daß bspw. beim "Drucken" eines Xpress-Dokuments auf einen speziellen Spooler (eine Dalim, die das Xpress-Dokument in zwei Dokumente, eine sog. Endseite und einen "Schwarzwechsler" aufteilt und das als Bildformate irgendwo ablegt) auch noch aus dem PS- bzw. späteren PDF-Code die Namen/Pfade aller platzierten Bilder ausliest, um diese zu sammeln und zusammen mit der Endseite ans andere Ende der Welt schiebt, weil dort "Endseitenharmonisierung" (d.h. Einzelbildretusche, so daß alle Bilder auf der Doppelseite zusammen passen) betrieben wird.
In meiner aktiven Zeit habe ich OPI sehr stark genutzt, um schneller zu produzieren (nicht, weil Grobbilder kleiner sind und damit schneller durchs Netz gegen sondern weil man mit OPI Arbeitsabläufe, die eigentlich nacheinander ablaufen müssten, parallelisieren kann) -- und damit Kunde um Kunde abgefischt, weil man denen spätere Abgabetermine zusichern kann und trotzdem früher/sicherer an die Druckerei liefert. Und netterweise auch noch höhere Seitenpreise als die Konkurrenz verlangen kann.
Oder daß die im Dokument platzierten Bilder getrackt werden (weil die Mutterfirma nur auf dem Weg rausbekommt, was die internationalen Tochtergesellschaften so alles grad bewerben) oder je nach Ausgabevariante durch "schöne" SW-Bilder ausgetauscht werden oder aber durch Varianten, die mit PDFMarks angereichert wurden und im anschließenden PDF-Dokument dann zu klickbaren Hyperlinks direkt in die Bilddatenbank führen. Etc. pp.
Das ist das, was ich mit "Workflow" meinte. Ziemlich speziell und eher auf Masse bzw. smarte Produktion ausgelegt. Und all das kann man seit Xpress 7.0 in die Tonne treten, weil Transparenzreduzierung unkontrolliert zuschlagen kann und einem den Zugriff auf platzierte Bilder im Spoolfile bzw. entstehenden PDF verunmöglicht (seit 8.1 zwar entschärft aber sobald ich das Ganze Spielchen auch rekursiv spielen möchte, also Dokumente als PDF platzieren möchte, in denen wiederum Bilder platziert sind, hab ich auch verloren).
Ergo: Spezielle Anforderungen aus einer völlig anderen Ecke als die, die jemand kennt, der einfach nur Akzidenzen in Xpress setzt [:)].
Davon abgesehen: Ich hab vorhin noch kurz 'nen Test gemacht und ein PDF/X in Quark 9.5.2 platziert und das Ganze wiederum als "PDF exportieren" lassen.
So, was passiert unter der Haube? Das platzierte PDF wird bei der Ausgabe temporär in ein EPS gewandelt (über den Konterpart des JAWS-PS-Interpreters: die "Jaws Xlat"-Library, die (E)PS/PDF in -- bereinigtes -- (E)PS umwandelt. Das entstehende EPS enthält alle Bildobjekte des ursprünglichen PDF unkomprimiert (d.h. wenn im ursprünglichen PDF JPEGs waren, werden die erneut komprimiert, was in nahezu 100% der Fälle Qualitätsverlust bedeutet). D.h. auch: für das 1,3 MByte große PDF entstand eine über 31 MByte große EPS-Datei.
Wenn man nun noch im Hinterkopf hat, was es alles in PDF gibt, das in PostScript keinerlei Äquivalent hat (einfach weil PostScript seit 15 Jahren tote weil nicht mehr weiterentwickelte Technologie ist und sich rein zufällig die Welt noch dreht), dann ist klar, daß da im Zweifel noch 'ne Menge mehr auf der Strecke bleibt:
- ICC-basiertes Farbmanagement (gibt's in PS nicht, nur CSA/CRD)
- Bildformate mit 16 Bit Farbtiefe
- JBIG2/JPEG2000-Kompression
- Transparenz (Umweg über PDFMarks in Xpress -- aber eben nicht für platzierte Objekte!)
- Ebenen, sog. "Optional Content Groups" (geht direkt aus Quark per PDFMark aber wiederum nicht, wenn [URL "http://www.prepressure.com/pdf/basics/refrying"]Refrying[/URL], also das Umwandeln von PDF nach PS nach PDF im Spiel ist)
Was mit nicht visuellem Inhalt in platzierten PDFs passiert (Hyperlinks, Annotations, Formulare, u.v.a. Metadaten) passiert, werde ich mir jetzt gar nicht mehr anschauen, die Ausgabe für das 9.x-Upgrade wird jetzt einfach mental abgeschrieben (war eigentlich für die zwei unserer Kunden gedacht, die durch deren Kunden noch zu Quark verdonnert sind. Aber ich schieb da jetzt den Riegel vor außer Xpress 10 kommt mit PDF-Unterstützung. Und XMP, der andere Showstopper für Dokumente in Workflows)
Antwort auf: In meinem Fall: ich habe nahezu nie platzierte PDFs, und die paar wenigen, die Probleme machten, kamen ausnahmslos alle und ohne Transparenzen aus Adobe-Programmen.
Der Satz müsste doch eigentlich richtigerweise lauten "die paar wenigen, die
in Xpress Probleme machten"? Xpress kann halt leider kein PDF. XPress kann nur (E)PS. PDFs werden beim Import und der Ausgabe durch JAWS Xlat-Engine gejagt, die aus PDF fürs Layout 'ne pixelige Voransicht und für die Ausgabe wieder EPS macht (in meinem vorherigen Test allen Ernstes PostScript Level 2 -- will jetzt gar nicht wissen, wie das Ding mit PostScript 3 Features wie Smooth Shades oder DeviceN und dergleichen im PDF umgeht), dieses temporäre EPS wird dann irgendwie in den PS-Code, den Quark beim "PDF-Export" erstellt, eingebaut, und dann kommt der andere Part der JAWS-Engine, nämlich der PS-zu-PDF-Konverter zum Einsatz. Mit anderen Worten: Dein PDF wird nicht als PDF genommen sondern einmal sauber durch den Wolf gedreht. Abgesehen von der Ressourcenverbrunzung (PDF zu (E)PS zu PDF) geht dabei halt evtl. auch so das ein oder andere schief, grad wenn das PDF ein klein wenig moderner als die antiquierte Software-Umgebung, die Xpress/JAWS erwarten, ist.
Antwort auf: Die schlecht aufgebauten Dokumente von Anderen: da geben sich QXP- und ID- (oder früher auch FH-)Nutzer überhaupt nichts.
Das stimmt allerdings. Aber wie oben schon gesagt -- andere Perspektive: Mir geht's um die "Weiterverarbeitbarkeit" von Dokumenten. Und da fällt Quark seit Version 7.0 unangenehm auf bzw. raus (Transparenz auf der kreativen bzw. unabsichtlich verwendeten Seite anbieten und dann ausgabeseitig nicht Transparenz wirklich unterstützen, und immer noch kein nativer PDF- und anscheinend gar kein XMP-Support)
Gruss,
Thomas
