Der Verein für saubere Druckdatenerstellung, PDFX-ready, hat einen neuen Leitfaden veröffentlicht. Dieser steht ab sofort zum kostenlosen Download bereit.

Der Leitfaden beschreibt über die Grundlagen der PDF/X-Standards, dem korrekten Layoutaufbau, der PDF-Ausgabe, den PDFX-ready Prüfprofilen, Transparenzen, Farbmanagement und Proofs bis hin zu Druckstandards die komplette Bandbreite moderner PDF-Workflows.

In der Arbeitsgruppe Technik von PDFX-ready haben wir dieses Werk in den letzten Monaten ausgearbeitet. Wir hoffen, dass der Leitfaden zur interessanten und lohnenden Lektüre für alle “PDF/X-ler” wird.

Über die letzten Monate haben wir bei PDFX-ready fast alle Settings und Empfehlungen überarbeitet und optimiert. Die neuen Vorgaben tragen die Versionsnummer V1.3. Dabei ging es dieses mal nicht um einschneidende Änderungen sondern um viele kleine Verbesserungen im Detail:

• PDF-Prüfprofile V1.3: Hier wurden hauptsächlich die neuen Farbprofile der ECI integriert und die Prüfungen des Gesamtfarbauftrags angepasst. Weitere Details im Changelog.
• Bridge Settings V1.3: Auch hier wurden die neuen ECI-Farbprofile eingesetzt.
• PDF-Exportstile V1.3 für InDesign CS4: Die JPEG-Kompression erfolgt ab sofort mit “maximaler” Qualität (vorher: “hohe” Qualität). Diese Änderung ist notwendig geworden, da mit InDesign CS4 bei gleichen Einstellungen wie in CS3, eine wesentlich niedrigere Ausgabe-Qualität der Bilder erreicht wird. Ein sofortiges Update wird daher empfohlen.
• Live-Preflight V1.3 für InDesign CS4: Hier wurde ausser der Versionierung nichts angepasst.
• PDF-Exportstile V1.3 für XPress 7 und 8: Kompression analog zu InDesign angepasst; Transparenzverflachung für importierte transparente PDFs definiert (nur XPress ab 8.1); neue ECI-Farbprofile integriert.

Alle Einstellungen gibt es wie gewohnt im Download-Bereich von PDFX-ready.
Wir, die Arbeitsgruppe Technik von PDFX-ready, sind natürlich immer an Ihrem Feedback interessiert.

Im Januar wird noch der neue PDFX-ready Leitfaden veröffentlicht, der die Qualitätsstandards von PDFX-ready  vor allem für Einsteiger durchgängig beschreibt.

Die große Aufgabe für 2010 ist nun der PDFX-ready Workflow V2.0. Darin sollen erstmals Regeln für PDF/X-4 basierte PrePress-Workflows (mit und ohne RGB) beschrieben werden. Natürlich sind wir auch hier stark an Ihrem Feedback aus der Praxis interessiert.

Darin wird das gesamte Spektrum der sicheren Druckproduktion mit dem Layoutprogramm erklärt: Von der Konfiguration des Farbmanagements über die ideale PDF-Ausgabe bis hin zu den besten Tipps aus der Produktions-Praxis.

Mit knapp 200 Seiten, einem separat beigelegten Farbmusterbuch, einem 10-seitigen Papiermusterbuch und der neuen Cleverprinting-Testform 2009 bietet die aktuelle Ausgabe einen umfassenden Überblick über die moderne Druckdatenproduktion.

Das Cleverprinting-Handbuch 2009 ist etwas besonders: Keine andere Publikation in Deutschland nimmt sich dem komplexen Thema Druckdatenproduktion so umfassend und zugleich verständlich an. Hinzu kommt, dass das Thema nicht nur erklärt wird, sondern mit Vergleichsdrucken, Farbmustern und vielen beeindruckenden Beispielen auch zeigen, dass PDF/X und Colormanagement auch wirklich funktionieren!

Das Cleverprinting-Handbuch 2009 kann unter http://www.cleverprinting.de völlig kostenlos und ohne lästige Registrierung herunter geladen werden, für 19,80 Euro ist eine hochwertig im Bogenoffset gedruckte Version erhältlich.

Aus dem Newsletter von PDFX-ready:

PDFX-ready hat heute neue Settings und Prüfprofile für die Adobe Creative Suite 3 und 4 zum kostenlosen Download bereitgestellt:

PDF-Exportstile für Adobe InDesign CS3 und CS4 Farbvoreinstellungsdateien für die Adobe Bridge CS3 und CS4 (bzw. für die Einzelprodukte der Creative Suite) PDF-Prüfprofile für Adobe Acrobat 8 und 9

Diese Settings stellen als Workflow-Version 1.2 die Empfehlung von PDFX-ready für Abläufe auf Basis von PDF/X-1a dar. Zu finden im Download-Bereich:

Adobe CS Workflow

Weiterhin wurden zwei neue Dokumente veröffentlicht die Hintergrundinformationen und Empfehlungen für den optimalen PDF-Workflow geben:

Farbmanagement und PDF/X

Ausgabebedingungen

Die Settings für QuarkXPress und PitStop sind in Entwicklung und werden demnächst aufgeschaltet.

Natürlich sind wir (der Arbeitskreis Technik von PDFX-ready) immer an Ihrem Feedback zu den Settings interessiert.

Der Bundesverband Druck & Medien (BVDM) hat vor kurzem ein Update für die Publikation “Farbmanagement in DTP-Anwendungen” veröffentlicht. Der dritte Teil der Serie behandelt die Creative Suite 3 sowie XPress 7. Zusammen mit Florian Süßl von MetaDesign und Sebastian Nafroth von 3f8h.net durfte ich als Co-Autor an diesem Projekt mitarbeiten.
Behandelt werden wieder die drei Workflow-Typen early, intermediate und late binding. Wichtigste Neuerung ist dabei, dass für late binding nun PDF/X-4 (also inklusive Transparenzen) verwendet wird. Da weder XPress 7 noch XPress 8 die native Ausgabe von Transparenzen ermöglichen bleibt dieser Workflow hier außen vor. Die Empfehlungen für XPress 7 stellen für mich die Quintessenz von zwei Jahren CMS in XPress 7 dar. Der Erwerb der toll ausgestatteten grünen Mappe sei daher allen “Farb-Entscheidern” ans Herz gelegt.

http://www.bvdm.org/Publikationen/

Ausgangspunkt ist eine Vektor-EPS-Datei aus Illustrator CS 2 die verschiedene Finessen enthält. Dazu im Detail mehr an den jeweiligen Stellen.
Die Präferenz, von der in diesem Artikel die Rede ist, findet sich in den Farbmanagement-Vorgaben für Print-Layouts von XPress 7:

Im ersten Schritt deaktivieren wir das Vektor-CMS und geben im Modus “Composite CMYK” aus. Dieser Modus gibt nur 4C aus, Sonderfarben werden in 4C konvertiert. Sollten. Denn bei ausgeschaltetem Vektor-CMS wird das Vektor-EPS unverändert ausgegeben, d.h. hier bleiben die Sonderfarben erhalten!

Das ist die erste Regel des Vektor-CMS: Ist es nicht aktiviert, wird das EPS immer ohne Änderung ausgegeben, unabhängig von dem was mit den Farben im restlichen Dokument passiert.

Die zweite Regeln betrifft das Softproofing (Darstellung der Farben in XPress) von Vektor-Daten: Bei deaktivierten Vektor-CMS findet keine akkurate Farbdarstellung von Vektor-EPSen statt. Deutlich wird das an diesem Screenshot und der Darstellung von Magenta im EPS sowie als native XPress-Fläche:

Aktivieren wir zum Vergleich das Vektor-CMS (und wichtig: laden das Bild neu): Nun “stimmt” das Softproofing des Vektor-CMS mit dem des restlichen Dokuments überein!

Sprich: Ist Vektor-CMS aus, interessiert sich XPress nicht für das Vektor-Bild, die Farbdarstellung erfolgt “irgendwie”. Nur bei aktivem Vektor-CMS wird das Bild überhaupt in die Farbmanagement-Überlegung mit einbezogen. Das ist der Hauptvorteil von aktivem Vektor-CMS.

Was heißt das aber für die Ausgabe?

Wiederholen wir die Ausgabe mit “Composite CMYK” (4C OHNE Spot) bei aktivem Vektor-CMS: Nun sind auch alle Sonderfarben im Vektor-EPS ICC-basiert nach 4C aufgelöst worden.

ABER:
Alle anderen Bestandteile des Vektor-EPS AUCH! Die Folge ist:
- Schwarz/Grau ist 4farbig aufgebaut.

- Vormals reine Farben sind verschmutzt

Die Wandlung von Sonderfarben ist inkonsistent zur Wandlung die XPress bei nativen Sonderfarben-Objekten vollzieht: Erstere erfolgt ICC-basiert, bei der zweiten wird dagegen der Alternate Color Space zugeordnet.
Jedoch ist selbst innerhalb des EPS die Wandlung nicht konsistent, da bei einem Verlauf mit Sonderfarbe auch einfach nur der Alternate Color Space aufgelöst wird (also hier keine ICC-basierte Wandlung)!

Verwenden wir als nächstes eine Farb-Ausgabe die Sonderfarben erlaubt: “Composite CMYK und Volltonfarben”. Jetzt bleiben die Sonderfarben im EPS erhalten. Die Schnittflächen von transparenten Sonderfarben und 4C-Objekten werden aber einfach in 4C aufgelöst.

Für den Rest ergibt sich ein gewohntes Bild: Das ganze EPS wird nach mal via ICC durch die Farb-Waschmaschine geschleudert!

Ähnliches ergibt sich auch bei den Ausgabemodi RGB, Graustufen und DeviceN.

Interessant ist folgendes Detail: Verläufe innerhalb des EPS werden zu Bildern gewandelt und NICHT als Smooth Shading ausgegeben! Diese Bilder haben immer eine Auflösung von 103 ppi! Ausnahme ist auch hier wieder der Verlauf zur Sonderfarbe, dieser wird als einziger in der korrekten Form des Smooth Shadings ausgegeben.

Zusammenfassend: Bei Composite CMYK oder DeviceN Modi ist das Vektor-CMS NICHT zu gebrauchen, da immer das komplette EPS ICC-basiert gewandelt wird und Verläufe zu Bildern werden.

Wie sieht es aber im Modus “Unverändert” aus?

Gemeint ist hier der von PDFX-ready benutzte Modus OHNE geräteneutrale Farbe.
Wird hier das Vektor-CMS aktiviert erhält man ein korrektes Softproofing des Vektor-EPS. Der Clou ist nun, dass die Ausgabe “unverändert” erfolgt. D. h. in das Vektor-Bild wird nicht mehr eingegriffen!

Im Modus “Unverändert” ist es also möglich den Vorteil des Vektor-CMS (korrektes Softproofing) mit einer sicheren Farbausgabe zu kombinieren.

Es kann also NUR beim Einsatz der Stile von PDFX-ready empfohlen werden, das Vektor-CMS einzuschalten!

Sind im platzierten EPS oder PDF übrigens kalibrierte Farbräume enthalten werden diese bei der “unveränderten” Ausgabe dekalibriert. Dies ist wahrscheinlich dem Zwischenschritt PostScript beim PDF-Export geschuldet.

Georg Obermayr, Januar 2008

Ein CMS-Workflow auf Basis von Job Jackets hat nicht nur Vorteile, sondern auch ein paar Nachteile. Diese sind sicherlich auch der Implementierung von Quark geschuldet. Im Moment gilt es aber, um diese Dinge herum zu arbeiten oder aber – falls es gar nicht anders geht – alternative Lösungswege zu suchen.

Der nachfolgende Bug wurde in QuarkXPress 7.2 behoben. Allen Anwendern des defaultjackets.xml sowie verfahrensangepasster Spazial-Jackets wird daher dringend die Durchführung dieses Updates empfohlen!

Bug in Zusammenhang mit defaultjacket.xml
Wird über “Neu von Ticket” auf Basis eines der Job Jackets ein neues Dokument erzeugt, so sind die Konfigurationen für Quelle und Ausgabe nicht richtig gesetzt. Die Evaluierung findet den Fehler. Dies geschieht nur dann, wenn als defaultjacket.xml ebenfalls eines der mitgelieferten Jackets gesetzt wird (etwa das für ISOCoated_v2_eci). Wird dagegen das “leere” Standard-defaultjacket genutzt, so erfolgt auch das CMS-Setup einwandfrei.

Es gibt also zwei Workarounds:
- Wird nur sehr selten auf vom Standard abweichende Ausgabebedingungen zurückgegriffen, so kann das defaultjacket.xml genutzt werden. Dieses sollte dann temporär ersetzt werden, wenn sich am Ausgabeziel etwas ändert.
- Wird in der Produktion mit vielen verschiedenen Ausgabebedingungen gearbeitet, so sollte unbedingt auf ein “spezielles” defaultjacket.xml verzichtet werden. Steuern Sie alle Job Jackets über “Neu von Ticket” an und deaktivieren Sie die mehrfache Nutzung (alternativ kann auch auf Finder-Ebene geschützt werden).

Dieser Bug besteht in Version 7.1. Es ist zu hoffen, das Quark hier in zukünftigen Versionen nachbessert. -> In Version 7.2 passiert!

Entfallener “Neu” Dialog beim erstellen eines Dokuments
Das fällt sicherlich am schnellsten auf: Beim gewohnten Erstellen eines neuen Dokumentes fehlt beim Einsatz des defauljacket.xml der altbekannte Dialog von Seitenformat, Rändern, Spaltenzahlen usw.
Dies ist leider einer etwas unglücklichen Umsetzung von Quark geschuldet: Sobald im Job Jacket konkrete Dokument-Vorgaben gemacht werden (hier konkret Quelle und Ausgabe und Proofing-RI) entfällt dieser Dialog, auch wenn seine Einstellungen hier gar nicht vom Job Jacket betroffen sind!
Das neue Dokument wird automatisch auf Basis der zuletzt »konventionell« erstellten Datei konfiguriert. Wurde zuletzt in A4 mit zwei Spalten auf Doppelseiten gelayoutet, haben auch die zukünftigen Job Jacket-Dokumente dieses Format. Das sollte bedacht werden, um hier eine saubere Ausgangsbasis zu erhalten.
Workaround zu dieser Sache ist das nachträgliche Ändern der Layouteigenschaften bzw. Musterseiten-Einrichtung.

XPert Tools Pro und das defaultjacket.xml

Kommt die neu verfügbare XTension XPert PageSets aus der Sammlung XPert Tools Pro in einer Umgebung mit dem defaultjacket.xml zum Einsatz, gibt es leider eine Inkompatibiltät. Der „Neu“-Dialog der XTension bietet zwar die Möglichkeit Stile für die Dokumenteinrichtung auszuwählen und zu erstellen, jedoch stimmen dann die CMS-Einstellungen des defaultjacket.xml nicht! Das enstehende Projekt hat zwei Layouts: „Layout 1“ mit der korrekten CMS-Konfiguration und „Layout 2“ ohne JJ-CMS-Einstellung. Dafür sind im „Layout 2“ dann die PageSet Einstellungen zum Tragen gekommen.
Es kann also aktuell nur davon abgeraten werden, die XPert PageSets XTension gemeinsam mit einem defaultjacket.xml einzusetzen!

Ändern des Job Jackets für Job Jacket-Laien sehr komplex
Da das Arbeiten mit Job Jackets hier nicht dem gewohnten „Vorgaben-Denken“ der XPress-User entspricht, gestaltet sich die Korrektur des Job Jackets u.U. etwas schwieriger. Möchte man etwa ein anders Ausgabesetting definieren, so muss dieses nicht nur zuerst korrigiert und gesichert werden, sondern auch anschließend im Job Jacket Manager beim entsprechenden Job Jacket zur Anwendung gebracht werden. Das erfordert ein gewisses Hintergrundwissen über die Zusammenhänge und ist auf jeden Fall nochmals ein zusätzlicher Lernschritt.
Auch wenn die notwendigen Schritte relativ simpel zu erklären sind, so dürfte das wohl trotzdem einige bereits abschrecken.

Georg Obermayr, Januar 2007

Es gestaltet sich also folgenden Situation: Sie erstellen als Programm-Präferenz eine Softproofing-Einstellung und verdrahten diese entsprechend. Die Einstellung wird zum voreingestellt Softproof aller zukünftiger Dokumente. Soweit so gut, nichts tut sich: Die Softproofing-Einstellung wird zwar in das Dokument mit eingebunden, jedoch nicht in das Job Jacket und ist somit auch nicht Bestandteil der beschriebenen, manifestierten und verifizierbaren Setup-Beschreibung des Dokumentes.

Jetzt passiert eines der folgenden Dinge (ohne Anspruch auf Vollständigkeit):
- Sie ersetzen in der Programmvorgabe, die alte Softproofing-Konfiguration durch eine neue, z.B. auf Grund eines Updates (mit neuem Namen).
- Sie geben das Dokument an jemanden weiter, der dieses Softproofing-Setting bei sich nicht geladen hat, oder anders benannt hat (kann auch die Druckerei sein!).
- Oder eine andere Konstellation, in der das ursprüngliche Softproofing-Setup aus irgendwelchen Gründen als Programmpräferenz nicht mehr verfügbar ist.

Öffnen Sie in einer solchen Situation das Dokument wieder, kommt die angesprochene Warnmeldung:
“In diesem Projekt werden benutzerdefinierte Farbkonfigurationen verwendet, die Ausgabe auf Anzeige und Ausgabe der Layouts haben. Fügen Sie für eine konsistente Anzeige und Ausgabe diese Farbkonfiguration dem Job-Ticket des Projektes hinzu”
Und dann die beiden angesprochenen Möglichkeiten “Hinzufügen zum Job-Ticket” oder “Ersetzen durch Standard-Konfiguration”

Der erste Fall, zum Job-Ticket hinzufügen:
Das wäre eigentlich die zu präferierende Option: Das Softproofing-Setup wird in das Job-Ticket gelegt und damit zur manifestierten und verifizierbaren Einstellung. Im Job Jackets Manager lässt sich nachprüfen, dass der “Ort” gewechselt wurde. Grundsätzlich ist das gut so, denn zukünftige Anwender müssen sich bei oben beschr. Konstellationen nicht mehr mit dieser Meldung herumschlagen, das CMS wurde “transportabel”. Es gibt jedoch einige Dinge, die nicht ganz sauber sind:
- Der Name der Einstellung geht verloren. Diese heißen jetzt kryptisch “Neue Ausgabeeinstellung X”. Das wird dadurch verschlimmert, dass
- auch im Menü Farbeinstellungen -> Ausgabe… die Konfiguration des Settings nicht einsehbar ist.
- Ich somit auch keine Möglichkeit mehr habe, die Einstellung zu verändern.

Einzig über den JJ-Manager wäre eine Info über den Inhalt möglich, eine Modifikation jedoch nicht…

Also sehr ungünstig, besonders wenn viel mit CMS experimentiert wird und Namen/Inhalte von Settings wechseln bzw. Daten weitergegeben werden. Ich habe selbst einige solche Dateien, welche fast unmöglich zu handeln sind.

Der zweite Fall, wechseln auf den Standard:
Hier wäre es wohl aus in bestimmten Fällen wünschenswert, XPress 7 würde auf den aktuell geltenden Standard wechseln. In der Tat wird hier anders gearbeitet. Die für benutzerdefinierte Ausgabe-Setups verfügbaren Modi:
Separation//Host/in-RIP
Composite//Grausufen/RGB/CMYK/AsIs/DeviceN
werden den acht von Quark mitgelieferten Ausgabe-Setups zugeordnet:
Prozess und Vollton, Zu Vierfarbauszug konvertieren/In-RIP Auszüge
Graustufen/Composite-RGB/Composite-CMYK/Unverändert/Zusammengesetze CMYK und Volltonfarben

Nicht der neuer CMS-Standard ist also ausschlaggebend, sondern ein fest verdrahteter Fallback auf Basis von ursprünglichem Ausgabemodus/Farbmodus. Die Denke dahinter ist klar: Wird eine solche Datei weitergegeben, kann nur garantiert sein, dass der Empfänger die acht Standard-Settings besitzt, nicht jedoch den beim Datenersteller aktuellen Standard!

Wird klar, warum bei XPress 7 die Notwendigkeit für diese Meldung entsteht? Ist die ursprüngliche Programmeinstellung nicht mehr vorhanden, muss eine Entscheidung getroffen werden. Wandeln in eine Dokumenteinstellung durch das Job Jacket zur konsistenten Wiedergabe? Fallback auf die fest definierte, verfügbare, passende Programmeinstellung?

Was also tun? Man könnte
- versuchen die Basis-Ausgabeeinstellungen zu hacken…
- Skripte erstellen um nach dem automatischen Fallback auf den neuen “Standard” zu wechseln. Dabei darf aber nichts in das JJ kommen.

- Das CMS-Setup gleich auf Basis von Job Jackets erstellen. Dann wäre diese Meldung von Haus aus unterdrückt, die Darstellung immer konsistent, der Name “lesbar” und das Setting editierbar. Dazu gibt es auf dieser Website ein Projekt mit Downloads und Beschreibungen.

Es wäre der sicherste Weg, um die Integrität der Altdaten zu erhalten und gleichzeitig nicht ständig mit “Neuen Ausgabeeinstellungen” konfrontiert zu werden.

Generell tut sich hier aber ein neuer Problemkreis auf: Das JJ ist ja intern und “abgekapselt” von der Außenwelt. Ändern Sie also etwas an Ihrem “Standard” (was ja durchaus auch innerhalb des Basis-JJ passieren kann), bekommt das bereits bestehende, interne Ticket das nicht mehr mit und geistert im schlimmsten Fall mit veralteten Settings herum. Was es also bräuchte, wäre dann an dieser Stelle wiederum ein Abgleich zwischen internen JJ und Basis-JJ.

Georg Obermayr, März 2007