DTP heisst auch Ausgabe �und Ausgabe heisst leider PDF

Während Jahrzehnten kontrollierte Adobe die professionelle Ausgabe von Dokumenten durch die Entwicklung einer auf die Ausgabe spezialisierten Seitenbeschreibungssprache. Mit PDF hat sich dies geändert. Das ist nicht nur gut. Diese Zeitreise blickt kritisch auf bald zwanzig Jahre PDF – zurück, aber auch nach vorne.

Jürgen Franck Im letzten Artikeldieser Serie zum Thema Publishing war die Rede von fehlenden Innovationen. Diese bezogen sich weniger auf das Fehlen von Funktionen in den Programmen. Im Gegenteil sind die beiden Platzhirsche Adobe InDesign und QuarkXPress heute mehr als ausreichend mit Funktionen für das Layouten ausgestattet. Wer mit weniger Funktionen auskommt, kann auf deutlichgünstigere Layoutprogramme wie iCalamus, Scribus oder VivaDesigner zurückgreifen, die auf der nächsten Seite kurz vorgestellt werden.

Fehlende Innovation sollte vor allem heissen, dass das Publishing heute einfacher sein könnte. Einfacher muss es wohl auch werden, wenn nicht die neuen Medien das technisch angestaubte Desktop-Publishing (DTP) bei der Informationsaufbereitung dereinst ins Abseits drängen sollen. Es scheint fast ein wenig so, als hätte niemand bemerkt, dass das klassische DTP längst nur mehr noch einer von vielen Medienkanälen ist – ein Teilbereich mit noch dazu abnehmender Tendenz.

Ausgabe = PostScript oder PDF

Ein Grund für die Schwerfälligkeit des Desktop-Publishing ist die zu enge Verknüpfung mit der Seitenbeschreibung. Mit einem Layoutprogramm werden dazu direkt (oder indirekt mithilfe eines Layoutservers, eines Redaktionssystems oder eines anderen Tools) primär druckausgabegerechte Dokumente erstellt. Die Dokumente werden mithilfe eines Druckertreibers und eines komplexen Exportmenüs in Ausgabedaten umgewandelt, die ihrerseits vom RIP in Bit­map-Daten für das Ausgabegerät (Drucker, Belichter) konvertiert werden. Heute handelt es sich bei den vom Layoutprogramm erstellten Daten in der Regel um PDF-Daten; alternativ können nach wie vor auch Daten im PostScript-Format erzeugt und davon mit Programmen wie dem Adobe Distiller ebenfalls PDF-Dokumente erzeugt werden (siehe Kasten). Je nach Vorgehen werden qualitätsentscheidende und druckrelevante Einstellungen entweder im Original-Layoutdokument oder – besser – zentral im RIP vorgenommen, um die Daten auftragsgerecht ausgeben zu können. Zu diesen Einstellungen gehören druckverfahrensspezifische Parameter wie Trapping (Über-/Un­terfüllen) oder die Separation der Bilddaten (mittels Farbprofilen). Je nach vorhandenem oder gewähltem Ausgabeworkflow unterscheidet sich der Ablauf teilweise grundlegend: Werden bereits separierte Bilddaten verwendet, kommt ein anderer Workflow zum Einsatz als bei der Verwendung von RGB-Daten, die mit einem Farbprofil und mit einer Ausgabe­absicht verknüpft werden müssen.

Die Generierung der Ausgabedaten kann prinzipiell verschiedenartig erfolgen: Wer nicht jedes Mal die Einstellungen von Hand vornehmen will, dem bieten sich so genannte Joboptions an, die vorkonfiguriert und als Einstellungen beziehungsweise Settings jederzeit geladen und angewendet sowie auch verteilt werden können. Dort wird zum Beispiel das Herunterrechnen von Bilddaten (Downsampling) auf die notwendige Ausgabeauflösung vorgenommen, werden die Passkreuze gewählt, wird das Vorgehen bei transparenten Objekten (Flattening) festgelegt. Der Nachteil dabei ist, dass sehr ausgabespezifische Daten erstellt werden; im Rahmen einer engen Kundenbeziehung (beispielsweise Agentur mit Druckerei) ist dies aber durchaus praktikabel.

Das Einrichten des Preflight-Bedienfelds in InDesign oder der Job Jackets in XPress wären ein weiterer Weg, um Ausgabefehler zu umschiffen, zeigen diese doch die abgefragten beziehungsweise konfigurierten Schwachstellen schon während der Dokument­erstellung auf.

Wer als Erzeuger von PDF-Dokumenten jedoch mehr Freiheit und damit Flexibilität möchte, setzt hier idealerweise auf einen PDF/X-Standard. Dieses PDF-Subset (Untergruppe) stellt sicher, dass die technischen Kriterien für eine professionelle Ausgabe erfüllt sind. Dabei ist PDF/X in dem Sinn aber kein Qualitätsstandard: Genauso wenig wie PDF/X typografische Einstellungen checkt, ist auch die minimale Bildauflösung kein Prüfkriterium.

Problemkind Kompatibilität

Das Erstellen von professionellen Ausgabedokumenten ist kein Kinderspiel. Daher ist es auf der einen Seite nicht nachvollziehbar, warum heutige DTP-Programme nicht längst näher an der Ausgabesprache sind. Warum können die beiden Layoutprogramme also nicht längst direkt «im» PDF-Format und damit mit echtem WYSIWYG arbeiten? Stattdessen ist der skizzierte, mühsame und aufwändige sowie letztlich fehleranfällige Export aus dem internen und somit proprietären Dateiformat der Software notwendig.

Leider sind wir im Publishing auch im Jahr 2012 noch in der Informatiksteinzeit: Beispielsweise der Austausch zwischen XPress- und InDesign-Dokumenten funktioniert immer noch mehr schlecht als recht. Er erfordert zusätzliche Konvertierungshilfsmittel wie die Programm­erweiterungen «ID2Q» oder «Q2ID». Interessanterweise bietet die holländische Softwarefirma Markzware, die für die erwähnten Dokumentenkonverter sowie für ihre Preflight-Produkte bekannt ist, seit Kurzem ein Produkt an, das ein mit dieser Thematik einhergehendes Problem angeht und bei nativen Layoutprogrammen obsolet wäre: Was tun, wenn keine Originaldaten vorhanden sind und nur die PDF- bzw. Exportdaten vorliegen, dieses Dokument aber in grösserem Umfang geändert werden muss? Die «PDF2DTP»-XTension von Markzware (bislang nur für Quark­XPress verfügbar) erlaubt das, was man durchaus als Reverse Engineering bezeichnen könnte: das Rückwandeln beziehungsweise das Erstellen eines Layoutdokuments auf der Basis eines PDF-Dokuments. Das Tool beweist, dass es technisch offenbar gar nicht so aufwändig sein muss, den vorgeschlagenen Weg eines echten PDF-Layoutprogramms in die Praxis umzusetzen; Von Adobe oder Quark werden wir ein solches «PDF-basierendes» Layouttool vermutlich nie zu sehen bekommen.

Änderungen bei der Ausgabe

Neben dem direkten Erstellen von Daten im PDF-Format wäre noch ein anderer, vermutlich gar noch besserer Ansatz denkbar: Wenn Adobe und Quark wohl auch in Zukunft auf ihre proprietären Formate setzen, warum dann nicht einfach den Export komplett ändern? Wie wäre es mit einer deutlich näher an das Webpublishing angelehnten Ausgabe, also quasi mit der Entwicklung eines HTML/XML-RIP samt zugehörigem, alternativem Produktions- und Ausgabeworkflow? Mit Cascading Style Sheets (CSS) in Verbindung mit XML und HTML5 könnten sich nach verschiedenen Anpassungen bestimmt auch komplexeste Druck­erzeugnisse erstellen und ohne jegliche Anpassung direkt im Browser darstellen und darin blättern lassen.

Warum wird dieser eher «web-zentrische» Ansatz nicht in die DTP-Welt überführt? Die Antwort mag lauten: weil sich HTML nicht für die Ausgabe auf einem CtP-Belichter eignet. Okay. Aber vermutlich stimmt das nur, weil das noch niemand richtig versucht hat. Wo liegen denn die Unterschiede – einmal abgesehen davon, dass ein professioneller HTML-Editor viel mehr zu leisten vermag als die DTP-Programme mit ihren eher bescheidenen XPress-Marken (XPress) oder dem Tagged-Text (InDesign). Und: So unterschiedlich komplex sind die beiden Welten DTP- und Webpublishing letztlich ja auch nicht. Die auf Anhieb auszumachenden Probleme sind: bisher fehlende typografische Funktionen (Kerning/Spationieren), fehlende Satzarten (erzwungener Blocksatz), fehlende Möglichkeiten zur Einbindung von Farbprofilen.

Dass all dies bestimmt möglich wäre, beweisen Vektorgrafiken. Solche lassen sich ja bereits aus Adobe Illust­rator heraus für ein gedrucktes (als EPS-Datei) oder für ein Webdokument (als SVG-Datei; XML-codiert) exportieren und im Browser gar vergrössern. An der Textkodierung und den Schriftformaten kann es auch nicht liegen: Unicode und OpenType-Fonts lösen hier viele bisherige Schwachstellen. Dabei würden viele dieser Funktionen dem Publishing als Ganzes guttun. Das meiste ist zwischen Web- und Desk­top-Publishing gar identisch: Rahmen, Linien, Konturen, Farben, Schrift, Ausrichtung, Tabellen … Es ginge eigentlich nur darum, die Unterschiede anzupassen, auszumerzen, zu egalisieren. Das CMYK-Farbmodell der Druckindustrie liesse sich mit Farbprofilen lösen: Je nach Ausgabeabsicht müsste statt einem RGB-Browserprofil ein druckspezifisches Profil eingebunden oder auf ein externes Farbprofil verlinkt werden (so wie es ja auch PDF/X-4p vorsieht …).

Man müsste  die erwähnten besonderen Anforderungen des DTP in das W3-Konsortium, das für die Weiter­entwicklung der Webstandards federführend ist, einbringen. Und der Begriff Webstandard müsste dann durch Publishingstandard ersetzt werden. Man hätte gleich mehrere Fliegen mit einer Klappe geschlagen.