In der neusten Version QuarkXPress 7.2 hat Quark das Interface zur Transparenz-Reduzierung erweitert und verfeinert. So ist es jetzt möglich die Berechnungs-Auflösung einzeln für Schlagschatten, Vektoren und Verläufe vorzugeben. Das bedeutet bessere Kontrolle und leichtere Einflussmöglichkeiten auf den kompletten Reduzierungs-Prozess. Was bringt diese Erweiterung und welche konzeptionellen Stolperfallen bleiben potentiell für die Anwender bestehen?

Dokument von Quark
Hier soll es nicht um eine grundsätzliche Beschreibung der Transparenz-Reduzierung von XPress 7.2 gehen. Quark hat dazu schon vor längerer Zeit ein Whitepaper vorgelegt, in dem es genau darum geht. Darin sind bereits die Basis-Konzepte sowie einige Best Practices gut beschrieben. Die Lektüre sei allen “Transparenz-Einsteigern” ans Herz gelegt.

Basics
Trotzdem stichpunktartig einige Basics, die im generellen für Transparenz-Reduzierungen und im speziellen für XPress 7.2 gelten:
- Transparenz muss aus XPress 7 immer reduziert werden, da keine native PDF-Ausgabe (auch nicht über den PDF-Export) zur Verfügung steht. Zwischenschritt ist immer PostScript, welches auf Grund seines Grafikmodells keine echte Transparenz unterstützt.
- Die Reduzierung erfolgt je nach an der Transparenz-Beziehung beteiligten Objekten auf reiner Vektor-Ebene oder auf Pixel-Ebene, bspw. durch das Rendern von Vektor-Objekten.
- Bei der Reduzierung auf Vektor-Ebene werden die transparenten Objekte in undurchsichtige Teil-Objekte zerschnitten, um so das transparente Aussehen zu erhalten.

- Bei der Reduzierung durch Rendern in Pixel-Objekte sind betroffen: Transparent gestellte Bilder, Alpha-Kanäle von Bildern, Schlagschatten ; Verläufe und importierte Vektorbilder (EPS, PDF), jeweils wenn sie in Transparenzbeziehungen stehen.

- Da die bei der Renderung entstehenden Pixel ja auf die spätere Ausgabequalität abgestimmt sein müssen, lässt sich dessen Auflösung in den entsprechenden Ausgabe-Dialogen für Drucken, EPS-, PS- und PDF-Export steuern. Separat stehen hier Einstellungsmöglichkeiten für Verläufe, Schlagschatten und Vektoren zur Verfügung:

Transparenz-Reduzierung wird in heutigen PostScript Ausgabe-Workflows (sei es im RIP oder im Layoutprogramm) die nächsten Jahre über eine technische Notwendigkeit bleiben. Da der konkrete Vorgang aber nicht programmübergreifend normiert ist, ist es wichtig, über die spezifischen Funktionsweisen in XPress 7 Bescheid zu wissen und Problemstellen gleich im Vorfeld zu umgehen.

Was ist mit Bildern?
Es fällt vielleicht als erstes auf, dass ein Parameter im Reduzierungs-Dialog von XPress zu fehlen scheint: Bilder.
In welcher Auflösung werden also zwei Bilder reduziert, die zueinander in einer Transparenz-Beziehung stehen?
Schauen wir uns dieses Beispiel an:

Das vordere Bild mit einer effektiven Auflösung von 90 ppi steht 50% Transparent auf dem hinteren Bild mit 288 ppi effektiver Auflösung.
Entscheidend für die Auflösung des zu reduzierenden Bereiches, also der Schnittstelle beider Bilder, ist jetzt nicht eine Einstellungsmöglichkeit im Ausgabe-Dialog. Sondern vielmehr das Bild mit der höchsten effektiven Auflösung! In diesem Fall erfolgt die Reduzierung also mit 288 ppi.

“Transparenzberechnungsoptionen”
Diesem Umstand Rechnung trägt die akkurate Benennung des Ausgabe-Dialogs: Ab XPress 7.2 heißt dieser “Transparenzberechnungsoptionen”. Damit beschreibt er genau, was er tut: Definieren, in welcher Auflösung Vektoren und andere XPress-Objekte gerendert werden sollen. Bilder sind hier kein Parameter weil sie ihre Auflösung ja selbst definieren.
Erweitern wir zum besseren Verständnis obiges Modell um einen Schlagschatten:

Als Berechnungsoption für Schlagschatten wurde 240 ppi eingestellt. Hier wird erneut deutlich, dass die Reduzierung des transparenten Bildteils (blau) völlig unabhängig von dieser Option ist. Diese greift erst, wenn es um die Berechnung der Auflösung des Schattens geht. Die finale Auflösung wird hier aus zwei Faktoren gebildet: Dem Bild auf welchem der Schlagschatten steht und der eingestellten Berechnungs-Auflösung.
XPress 7 arbeitet hier nach dem Prinzip “die höhere Auflösung gewinnt”. Hat das Bild die höhere effektive Auflösung wird in dieser gerendert, ansonsten in der eingestellten Berechnungsauflösung.

Transparenz und Farbmanagement
Transparenz-Reduzierung war wahrscheinlich der technische Hauptgrund für Quark, das Farbmanagement in XPress immer zu aktivieren. Wenn etwa ein CMYK-Schlagschatten auf einem RGB-Bild steht, dann muss für den Reduzierungs-Bereich eine Entscheidung getroffen werden: Reduzierung in RGB oder CMYK. Das bedeutet wiederum, dass mindestens ein Element farblich konvertiert werden muss. Dafür braucht es ICC-basiertes Farbmanagement, und, falls das ganze qualitativ anständig passieren soll, korrekt gesetzte Quell- und Zielprofile sowie Rendering Intents.

Die Entscheidung, welcher Farbraum Ziel sein soll bei Farbkonvertierungen im Zuge der Transparenz-Reduzierung, wird in den Ausgabe-Dialogen getroffen. Unter “Farbe”, “Einstellungen” wird indirekt auch das Zielprofil definiert.
Ist hier “Composite-CMYK” gewählt, dann ist das “Quark Generic CMYK”! In professionellen Umgebungen ist daher unbedingt von dessen Einsatz abzuraten – es sollten eigene Farbausgabestile erstellt werden, mit den passend hinterlegten Profilen.

Obwohl es technisch also möglich ist, sollte das Mischen zu vieler Farbmodi und Farbräume vermieden werden. Der Reduzierungsvorgang wird dadurch unnötig komplex und es erhöht sich das Risiko fehlerhafter Farbkonvertierungen. Dies gilt übrigens auch für die PDFX-ready Profile! D.h. auch im Modus AsIs erfolgen Konvertierungen von RGB nach CMYK sobald eine entsprechende Transparenz-Konstellation im Spiel ist.

Mit verschiedenen Farbräumen ist ebenfalls Vorsicht geboten. Trifft etwa ein ISO Newspaper Bild auf ein transparentes ISO Coated Bild kann dies u.U. zu unschönen Farbverschiebungen im Schnittbereich führen. Hier würde es dann Sinn machen für diese beiden Bilder auf Objektebene das CMYK nach CMYK Farbmanagement zu aktivieren.

Parameter 1: Vektorbilder
Schauen wir uns als nächstes die einzelnen Parameter an, die sich bei der Transparenz-Berechnung in den Ausgabe-Dialogen regeln lassen. Da wären als erstes “Vektorbilder”.
Dies betrifft keine XPress Rahmen oder Boxen – sondern importierte Bilder mit Vektoren innerhalb einer Transparenz-Beziehung. Also etwa Logos oder Zeichnungen als EPS (oder PDF) aus Illustrator oder Freehand. Nachdem auch hier Transparenz “berechnet”, also gerendert, wird, handelt es sich dabei um das wohl größte konzeptionelle Manko der Transparenz-Ausgabe aus XPress 7.
Wird z.B. ein Logo platziert und unter einem weißen Rahmen mit 50% Deckkraft gelegt, dann ist Adobe Flattening in der Lage die Vektoren bei der Reduzierung zu erhalten und mit den aufgehellten Farbwerten zu modifizieren. In XPress 7 wird das Vektorbild dagegen immer gerendert! Die Vektoren können also nicht erhalten werden.
Welche Auflösung für diese Reduzierung angesetzt werden kann hängt stark von der konkreten Situation ab. Je nach Platzierungs-Größe des Vektorbildes, inhaltlichen Aufbau der Vektoren (Rundungen, feine Elemente, Schrift usw.) und der Interaktion mit den transparenten XPress-Objekten kann auch eine relativ hohe Auflösung noch unbefriedigende Ergebnisse erzielen. Ein Startwert kann etwa der zwei bis dreifache Faktor der Bild-Downsampling-Auflösung (falls vorhanden) sein – es ist aber in den meisten Fällen notwendig die Ausgabe genau zu untersuchen und dann bei Problemfällen den Reduzierungswert stetig zu erhöhen. Ein paar Beispiele:

Hier wurde eine Illustrator-Zeichung mit einem Schlagschatten überdeckt. Berechnungsauflösung war 400 ppi, Downsampling anschließend ebenfalls 400 ppi. Es sind deutliche qualitative Unterschiede feststellbar, die sich auch im Druck bemerkbar machen werden.

Ein kleiner Einschub: In diesen Beispielen wird immer von einem Downsampling von 400 ppi gesprochen. Damit hänge ich mich an die Empfehlung von PDFX-ready Stand 06/2007. Dies heißt jedoch ausdrücklich nicht, dass ein solches Downsampling immer optimal ist, noch dass es in allen Fällen einzusetzen ist. In der Tat sind 400 ppi ein Kompromiss. Es ist daher von enormer Wichtigkeit diese Stellschraube zu kennen um bei qualitativ schlechter Ausgabe gegensteuern zu können. Eine Erhöhung des Downsampling-Zielwerts oder auch dessen komplettes Deaktivieren sollte immer mit Anpassungen der Reduzierungs-Auflösungen einhergehen.

Zurück zur Vektor-Reduzierung: Zum Vergleich das selbe Motiv mit einer Berechnungsauflösung von 600 ppi, Downsampling wieder auf 400 ppi:

Die Treppenstufen nehmen ab. Es ist zu beachten, dass beide Motive auf 400 ppi heruntergerechnet wurden, jedoch trotzdem von der erhöhten Berechnungsauflösung profitieren. Noch mal dieses Motiv mit 1800 ppi Berechnungsauflösung, Downsampling erneut auf 400 ppi:

Bei dieser hohen Auflösung nimmt jedoch die Ausgabezeit massiv zu!
In allen Beispielen entsteht zwischen dem reduzierten, gerenderten, Teil und dem als Vektor ausgegeben Teil des Bildes eine sichtbare Nahtstelle. Diese entsteht natürlich auch dann, wenn ein transparenter Rahmen nur minimal in das Vektorbild ragt:

Die einzige Lösung dieser Problematik – zumindest solange Quark hier nicht nachbessert – ist es, die Reduzierungs-Auflösung für Vektoren konsequent zu erhöhen und auch die korrespondierenden Downsamplings anzupassen. Dass dies auf Kosten von Ausgabe-Performance und Datenmenge gehen kann, steht – neben Speicherplatz-Problemen von QuarkXPress – auf einem anderen Blatt. Sollte es trotz ausgereizter Reduzierungs-Auflösung nicht möglich sein eine zufrieden stellende Ausgabe zu erreichen, muss der Effekt schlimmstenfalls in Illustrator vorbereitet oder mit nativen XPress-Objekten nachgebaut werden. Eine kritische Prüfung von Fall zu Fall ist bei diesem Manko der XPress 7 Reduzierung also unerlässlich.

Ein Workaround der übelsten Sorte ist es die komplette Transparenzregion mit einem weißen Rahmen zu überdecken und diesem eine minimale Deckkraft zuzuweisen (<1%). So wird ein gleichmäßiges Rendern des kompletten Bildmotivs erzwungen und es entstehen zumindest keine Sprungkanten zwischen gerendertem und vektorisiertem Bildteil. Da dies aber die Verarbeitungszeit massiv erhöht, in komplexen Situationen die Reduzierung fehlerbehaftet sein kann und meist auch qualitativ nicht viel rausholt, ist dieser Workaround in der Praxis eigentlich nicht zu gebrauchen:

Parameter 2: Verläufe
Wenn eine Farbe innerhalb eines Verlaufes transparent gestellt ist, dann rendert XPress 7 bei der Ausgabe den Verlauf zum Bild. D.h. er wird nicht als hochwertiges Smooth Shading ausgegeben, was für Verläufe das Optimum wäre, sondern als Pixel.
In vielen Fällen ist dies kein besonderes Problem, da der Verlauf in Bezug zu anderen Objekten steht. Hier kann die Auflösung dann auch relativ niedrig angesetzt werden.

Jedoch kann auch hier eine Erhöhung der Berechnungsauflösung bei gleichbleibendem Bild-Downsampling Qualitätsvorteile bringen.
Je nach Verlaufslänge und Tonwert-Unterschied zwischen Start und Ende kann es jedoch zu sichtbarer Streifenbildung kommen. Dies ist bedingt durch die 8 Bit-Kodierung des Bildes, welche nicht mehr als 256 Tonwertabstufungen pro Kanal erlaubt. Ein eindeutiger Nachteil gegenüber Smooth Shadings, welche eine geräteunabhängige Beschreibung des Verlaufes bedeuten.

Eine XPress 7-Spezialität ist der Verlauf zur Farbe “Keine”. Hier entsteht immer eine Transparenz-Beziehung, auch wenn der Verlauf für sich alleine steht! Ein solcher Verlauf wird also auch immer gerendert. Wenn es also grafisch nicht notwendig ist, sollte auf diese Verlaufsart verzichtet werden. Über ein Job Jacket lässt sich übrigens nach solchen Verläufen suchen.

Parameter 3: Schlagschatten
Dritter Parameter in dieser Liste sind die Schlagschatten. Auch diese werden bei der Ausgabe zu Bildern gewandelt.
Meist kann auch hier der Wert relativ gering angesetzt werden, sofern der Schatten sehr weich ist. Wurde der Schatten aber mit einem Weichzeichnungswert von 0 mm entworfen, muss die Auflösung erhöht werden. Dies sollte man aber generell vermeiden, da ein solcher “harter” Schlagschatten auch konventionell (mit zwei versetzten Textboxen) erzeugt werden kann – ohne dass später ein Rendering notwendig wäre.

Umgekehrt gilt, je weicher ein Schlagschatten ist, desto nieder kann die Reduzierungs-Auflösung sein. Auch hier kann eine Erhöhung der Berechnungsauflösung bei gleichbleibendem Downsampling Qualitätsvorteile einbringen.
Schwierig sind u.U. gedrehte Schlagschatten. Dieser Schatten wurde mit 400 ppi gerendert, Downsampling 400 ppi:

Zum Vergleich der selbe Schatten mit 800 ppi gerendert, gleiches Downsampling:

Problematisch bei Schlagschatten sind Vektor-EPSe mit minderwertigen, eingebundenen, Voransichten. Weißt man deren Inhalt in XPress 7 einen Schlagschatten zu, wird dieser nämlich bei der Ausgabe auf Basis der Qualität der Voransicht in der XPress-Layoutfläche wiedergegeben! Hat die Voransicht eines EPS also eine sehr schlechte Qualität wird dies u.U. auch auf die Ausgabequalität Einfluss haben. Besonders kurios wird dies bei EPSen ohne eingebundene Voransicht:

Der Bildrahmen (links die Darstellung in XPress) hat die Hintergrundfarbe “Keine”. Der zugewiesene Schlagschatten wirkt also auf den Inhalt des Bildes. Bei der PDF-Ausgabe (rechts) wird dann zwar das EPS korrekt ausgegeben (rotes Kreuz), der Schlagschatten selbst ist jedoch auf Basis der Darstellung in XPress berechnet!
Temporär umgehen lässt sich dies über Objekt -> Voransichtsauflösung -> Volle Auflösung. So wird XPress gezwungen selbst in das EPS zu schauen und eine vollwertige Darstellung auf der Layoutfläche wiederzugegeben. Generell umgehen lässt sich dieses Thema, indem man XPress anweist bei jedem Import eines Vektor-EPS selbst eine Voransicht zu berechnen. Dies geht über die Präferenz “Erzeugen” bei “EPS”.

Parameter 4: Gedrehte Bilder
Dieser letzte Parameter ist eine Eigenheit der XPress 7 Transparenz-Reduzierung. Relevant wird er, wenn folgende Konstellationen zusammentreffen:
- Bilder mit niedriger Auflösung
- werden gedreht oder geneigt
- und sind Teil einer Transparenz-Beziehung.
Es macht absolut Sinn in diesen Situationen die Option zu aktivieren, da die Bilder sonst sehr kantig und gepixelt aussehen – dieses Bild etwa hat eine Auflösung von 120 ppi:

Zum Vergleich das selbe Bild mit einem Upsampling auf 300 ppi für Bilder mit weniger als 200 ppi:

Auch wenn solche Situationen in der täglichen Praxis sicher nicht ständig vorkommen, sollte dieses Upsampling immer aktiviert werden, damit es später nicht übersehen werden kann.
Der erste Wert, der Zielwert der Hochrechnung, sollte auf den höchsten Wert der drei Berechnungsauflösungen für Vektoren, Schlagschatten und Verläufe gestellt werden. So wird vermieden dass später u.U. Sprünge zwischen verschiedenen Auflösungen entstehen können.
Der zweite Wert definiert den Schwellenwert für das Upsampling. Oberhalb dieses Wertes werden die Bilder nicht mehr angefasst! Dieser Wert hängt stark von der konkreten Situation ab, in vielen Fällen dürfte aber ein Wert, der 25% niedriger ist als der Zielwert ausreichen. Für 300 ppi also 225 ppi usw. Je nach Situation können hier aber auch andere Werte sinnvoll sein.

Ein paar Best Practices
Die richtigen Parameter bei der Ausgabe sind die eine Sache, mindestens ebenso wichtig ist es aber, bereits bei der Erstellung des Layouts einige grundsätzliche Funktionsweisen von Transparenz-Reduzierungen zu beachten. Denn es kann später nicht mehr ausgebügelt werden, was bereits bei der Seitenerstellung falsch gemacht wurde!

Eine der Grundregeln ist es, die Stapelreihenfolge von Objekten zu beachten. Die Reduzierung erfolgt auch in XPress 7 immer unter Berücksichtigung der Ebenen von einzelnen Objekten im Layout. Entscheidend wird dies, wenn etwa ein Schlagschatten von einer Textbox umflossen wird. Steht der Schlagschatten vor der Textbox, würde der Text bei der Ausgabe in Pfade umgewandelt. Da dies jedoch vermieden werden sollte, empfiehlt sich der Einsatz von zwei deckungsgleichen Objekten: Eines, mit dem Schlagschatten hinter dem Text und das zweite ohne Schlagschatten, dafür vor dem Text, also mit verdrängender Funktion. Dadurch wird das Pfaden des Textes vermieden und somit auch die Transparenz-Situation insgesamt vereinfacht.

Die zweite Grundregel betrifft das Aufziehen von Rahmen: Wenn Transparenz im Spiel ist sollten diese immer so eng wie möglich sein. D.h. Bild- oder Textrahmen sollten möglichst keinen überstehenden “Weißraum” haben. In XPress 7 gilt nämlich: Transparenz-Reduzierung findet nicht erst dann statt, wenn nur der Inhalt Teil einer Transparenz-Situation ist, sondern schon dann, wenn der Rahmen betroffen ist:

Steht hier das Vektor-EPS-Logo hinter dem großem Bildrahmen würde es bei der Ausgabe gerendert! Entscheidend ist also hier nicht der Inhalt des Rahmens mit Schlagschatten, sondern der Rahmen selbst.

Warum keine Empfehlung?
Was in diesem Artikel fehlt, ist ein konkretes Setting für pannenfreie Ausgabe von Transparenz. Es war auch mehr meine Absicht, klar zu machen, dass Transparenz je nach Situation gehandelt werden muss. Zu hohe Reduzierungsauflösungen können in vielen Fällen übertrieben sein und die Verarbeitungszeit unnötig verlangsamen. Umgekehrt haben niedrige Werte in bestimmten Konstellationen qualitative Einbußen zur Folge. Auch Aspekte wie Bilddownsampling und -Komprimierung sind hier relevant. All dies muss berücksichtigt und somit das Ausgabeergebnis von Fall zu Fall bewertet werden.
Werden jedoch die “Spielregeln” beim Layoutaufbau nicht beachtet hilft auch dies nicht weiter. Auch Aspekte wie die Inkompatibilität zu OPI-Systemen sowie Sprungkanten zwischen verschiedenen Auflösungswerten, die durch die Reduzierung entstehen können, sind zu berücksichtigen.
Trotz alledem ist Transparenz in XPress 7 auf der Ausgabe-Seite sicher zu handeln, so dass es eigentlich kaum einen Grund gibt, auf die neuen Gestaltungs-Möglichkeiten zu verzichten.

Georg Obermayr, Juni 2007

Browse Timeline

• « Artikel für den Cleverprinting Newsletter
• » FAQ: XPress 7 CMS Quelleneinstellungen von PDFX-ready?

Comments ( 8 )

Add a Comment