Martin Kraetke

Martin Kraetke

Interview am 16.10.2016

Welche Vorteile hat ein XML first-Workflow für Publikumsverlage?

Die Frage nach dem Workflow – XML first oder XML last – hängt immer vom eingesetzten Satzsystem und den bisherigen Manuskript-Workflows ab: Es ist also auch immer eine Frage der Software und der Inhalte.

Zum Hintergrund: Einen reinen XML first-Workflow findet man selten, weil der voraussetzt, dass der Autor schon XML-Daten liefert. Der Begriff XML first muss also weiter konkretisiert werden: In der Debatte in der Buchbranche geht es dabei um das Satzsystem, also die Frage, ob man aus XML heraus setzt (XML first) oder nach bestimmten Konventionen setzt und dann nach XML konvertiert (XML last).

Bei Publikumsverlagen ist das Satzsystem der Wahl zu 99% in Deutschland InDesign von Adobe und InDesign bietet einen XML-Import, der bei den XML first-Workflows genutzt wird. Dieser XML Import hat aber zahlreiche Einschränkungen: Auch wenn das gut klingt – von XML zu InDesign, nach den Korrekturen und dem Satz wieder in XML – ist es Augenwischerei.

Um XML sicher in InDesign zu importieren, muss man beispielsweise Tabellen und Absatz- und Zeichenformate vorher extra auszeichnen, damit die Daten sauber importiert werden können und automatisch erkannt werden. Beispielsweise müssen Bildverknüpfungen immer das Attribut href haben, in vielen XML Schemas wird das anders definiert. Außerdem kann der Import keine Hyperlinks, Querverweise, Fußnoten oder Indexeinträge – alles Dinge, die gerade für Publikumsverlage wichtig sind.

Dienstleister arbeiten mit Skripten für InDesign, um diese Fehler zu korrigieren und den Import zu ermöglichen. Ohne diese Skripte funktioniert der Import nicht. Adobe hat seit der Version CS4 nicht an diesem Problem gearbeitet. Für InDesign gilt: Der XML-Import ist eine tote Technologie. Wenn man InDesign als Satzsystem verwendet – und 99% aller Publikumsverlage tun das – ist XML first immer eine schlechte Lösung, einfach weil InDesign selber so wenig kann.

Außerdem sind nachträgliche Änderungen (Autorenkorrekturen) zwar sichtbar (WYSIWYG), werden aber nicht in die XML-Struktur übersetzt. Das was Du siehst und das was Du dahinter im XML hast, läuft also munter auseinander. Auch hier helfen weiter entwickelte Skripte, die aus Formatierungen Tags entwickeln, aber sehr komplex sind.

Gibt es nicht genug Interesse von Adobe, das weiterzuentwickeln?

Die Nachfrage nach XML-Lösungen ist bei InDesign nicht groß. Es gab Ende der 90er bis Mitte der 00er Jahre einen XML-Hype. Da war XML das Datenformat der Stunde. Für Adobe war das im Bereich structured data interessant und sie haben entsprechend eine halbgare Lösung erstellt, die für viele Dinge nicht funktioniert hat. Anschließend gab es keinen großen Druck auf Adobe, weil viele Verlage damals noch nicht über XML-Lösungen nachgedacht haben. Daher wurde es nicht richtig weiterentwickelt und außerdem sind Verlage nicht die größten Abnehmer und für viele von denen ist XML nicht so wichtig, viele sind noch garnicht so weit.

Parallel hat InDesign die InDesign Markup Language (IDML) entwickelt, die für XML last-Workflows benutzt werden kann. Dabei handelt es sich um einen ZIP-Container mit einer kompletten XML-Beschreibung von Layout und Inhalt, aus der sich eine semantische XML-Struktur erstellen lässt, sofern Absatz- und Zeichenformate eine semantische Bedeutung haben. Beispielsweise kann der in InDesign erstelle Index in einen richtigen Index umgewandelt werden – aus der IDML wird eine XML-Struktur. Der Vorteil ist, dass IDML aktiv von Adobe weiterentwickelt wird. Außerdem müssen die Satzbetriebe kein XML können sondern exportieren lediglich eine IDML, mit der man weiterarbeiten kann.

Welcher Prozess ist empfehlenswert?

Bei InDesign sollte ein XML last-Prozess bevorzugt werden. Sobald man Digital First-Publikationen produziert, kann man diese auch direkt aus einer Word-Datei oder einem CMS automatisch setzen. Sobald es um InDesign geht, funktioniert das nicht mehr.

Warum wird die medienneutrale Produktion beziehungsweise der XML first-Workflow so hoch gepriesen?

In der Theorie ist der XML first-Ansatz der richtige, in der Praxis jedoch nicht: Wenn die Software solche Defizite hat, dass der Content nicht richtig verarbeitet werden kann und die Gefahr besteht, dass die Autorenkorrekturen beziehungsweise der visuelle Satz und die XML-Struktur darunter auseinander laufen, ist das System instabil. Von daher ist das Paradigma eigentlich überholt.

Das Problem liegt bei InDesign: InDesign hat einen Marktanteil von 90% und daran wird sich absehbar nichts ändern, weil im WYSIWYG-Satz wahrscheinlich so schnell niemand zu InDesign aufschließen kann, immerhin stecken da jahrelange Entwicklungen drin.

Was ich für wahrscheinlicher halte ist, dass es Web-Apps geben wird und man mit einem Online-Editor Seiten setzen kann, immerhin kann man mit CSS3 jetzt schon Websites formatieren, Apps formatieren und E-Books formatieren. Mit dem CSS Paged Media Module funktioniert seitenbasiertes Layout schon jetzt, aber noch nicht so gut wie in InDesign. Es gibt beispielsweise nicht so viele typografische Möglichkeiten. Die Notwendigkeit, Content einmal zu produzieren und gleich in alle Kanäle zu spielen, wird aber immer mehr wachsen.

Bisher ist es nämlich so, dass die printorientierten Produktionsworkflows im Vordergrund stehen: Auch XML first ist printorientiert, weil die XML-Daten mit InDesign bearbeitet und normalisiert, danach wiederum als IDML beziehungsweise XML exportiert werden und daraus dann das E-Book generiert wird. Das ist ein verkappter XML last-Workflow.

Warum muss XML eigentlich aus InDesign nochmal exportiert werden?

Es wäre nicht notwendig, wenn es keine Textveränderungen gäbe. Einen Grobumbruch bekommt man auch automatisiert, kann Korrekturen daran wieder vorne in Word einpflegen und im Anschluss wieder einen Grobumbruch erzeugen. Wenn es im Feinumbruch aber noch Änderungen gibt, müssen diese in beide Formate nachgetragen werden. Daher ist es tauglicher, das XML wieder aus InDesign zu exportieren und alle Korrekturen mitzunehmen. Autoren geben üblicherweise erst dann die Imprimatur, wenn der Feinumbruch gemacht ist.

Solange die Workflows in den Verlagen printorientiert sind, lässt sich diese Praxis nicht abschaffen. Irgendwann ist ein automatisch generiertes PDF denkbar, das der Autor zugeschickt bekommt oder sich selbst erstellen kann und Korrekturen in einem Online-Editor vornimmt. Wenn dem Autor dieses Vorschau-PDF genügt, funktioniert der Workflow automatisch. Es gibt diese Beispiele, aber das steckt alles noch in den Kinderschuhen.

Warum steckt der vollautomatische Workflow noch in den Kinderschuhen?

Im Publikumsbereich ist das noch nicht denkbar, weil da sehr viel am gedruckten Buch hängt, gleichwohl wäre es im Bereich Selfpublishing möglich, weil die Anforderungen an das Produkt hier geringer sind.

Aber das Thema wird interessanter, irgendwo muss man schließlich Kosten sparen: Die Umsätze gehen zurück, die Auflagen gehen zurück, perspektivisch besteht auch eine Konkurrenz mit Netflix und Webdiensten. Es gibt einen gewissen Druck auf Verlage, die teilweise barock anmutenden Korrekturprozesse, die man Autoren gewährt hat, zu überdenken.

Wäre Feinumbruch per Knopfdruck möglich?

Bei einem automatischen Satz gibt es die Unterscheidung zwischen Grob- und Feinumbruch nicht mehr. Sobald man manuell eingreift, um den Umbruch zu beeinflussen – entweder über Befehle in XML oder im WYSIWYG-Satzsystem – spricht man von einem Feinumbruch. Bei geringen Qualitätsanforderungen kann ein Buch auch über den Grobumbruch in den Druck gehen.

Worin liegen dann die Nachteile und Risiken?

Es gibt typografische und sprachliche Qualitätskriterien, Autorenkorrekturen oder die Positionierung von Bildern, die händisch oder mit Skripten sichergestellt werden müssen. Das gleiche gilt für die automatische Silbentrennung, die Fehler produziert oder bei Fachwörtern große Lücken und einen unschönen Umbruch erzeugt, Hurenkindern und Schusterjungen. Was die typografische Qualität anbelangt sind die Deutschen übrigens auch pingeliger als beispielsweise die Engländer. Automatisch geht das nicht komplett, es sei denn, man gibt sich mit einer geringeren typografischen Qualität zufrieden.

Gibt es in den Verlagen emotionale Widerstände gegen die Umstrukturierung des Workflows?

Ja. Es gibt in Verlagen eine gewisse Resistenz gegen Veränderungen und auch gegenüber der Digitalisierung, die schon bemerkbar ist. Das ist keine reine Altersfrage, sondern eher eine Frage der Offenheit gegenüber Veränderungen. Und es ist auch klar, dass eine Branche, die sich lange darüber definiert hat, fast manufakturell und wenig automatisiert, schöne Gebrauchsgegenstände und Kulturgegenstände zu produzieren, das die ein anderes Verhältnis zur Digitalisierung hat als beispielsweise die Webentwicklungsbranche.

Außerdem hat die Digitalisierung die Branche überrollt und es wurde in vielen Verlagen zudem verpasst, die eigenen Mitarbeiter mitzunehmen im Sinne von Weiterbildungen und der Einbindung in die digitale Veränderungsstrategie. Denen wird nicht erklärt, wofür das gut ist und was die damit auch anfangen können – und so entstehen natürlich Ängste. Außerdem hat man möglicherweise typografische Vorstellungen, aber die E-Books können diesen typografischen Qualitätsansprüchen nicht gerecht werden.

Es gibt zudem die Angst, komplett eingestampft zu werden. Brockhaus konnte nach der Gründung der Wikipedia praktisch über Nacht (in drei, vier Jahren) dicht machen. Und es gibt eine berechtigte Angst, dass ein Global Player wie Google morgen mit einem neuen Geschäftsmodell kommt und auf einmal traditionelle Geschäftsmodelle überholt sind. Dadurch entsteht Druck bei der Digitalisierung mitzumachen, aber auch eine Unsicherheit, in welche Richtung man gehen solle. Aber die Risiken, keine E-Books zu produzieren oder die Leser nicht durch Angebote mit ins Web zu nehmen, ist groß. Da besteht die Gefahr, dass auch Autoren sagen: Ich will zu einem Verlag gehen, der für mich alle Kanäle organisiert.

Es gibt natürlich anderseits auch Autoren, die Angst haben, dass ihre Inhalte der Piraterie anheim fallen oder wirtschaftliche denkende Autoren, die wissen, dass bei einem E-Book deutliche weniger abfällt als bei einem gedruckten Buch.

Warum wird die medienneutrale Produktion trotz aller Nachteile als langfristiges Ziel betrachtet?

Viele XML first-Dienstleister haben in diese Technologie investiert und die selbstverständlich angepriesen. Jetzt wäre es teuer und unglaubwürdig, von dieser Empfehlung abzuweichen und alles aus IDML heraus zu machen. Viele glauben nach wie vor daran und empfehlen die Art und Weise so zu produzieren natürlich.

Eigentlich ist es aber auch nur ein verkapptes XML last, wenn Du das XML hinterher nachkonvertieren und nachbearbeiten musst, damit es funktioniert. Außerdem entsteht eine große Abhängigkeit hinsichtlich der unterstützten Schemata, weil man ein sehr einfaches, flaches XML Schema benötigt, weil das in InDesign nicht anders handhabbar wäre. Der Workflow ist meist auch nur für Publikumsverlage ausgelegt und funktioniert bei anspruchsvollen Publikationen im wissenschaftlicher Bereich beispielsweise nicht mehr. Außerdem gibt es Performance-Probleme bei InDesign.

Es besteht grundsätzlich ein Nachteil am XML last-Prozess: Man hat immer einen Medienbruch, weil man in IDML konvertieren muss und von dort wieder heraus. Allerdings ist die Automatisierung bei Publikumsverlagen generell schwer möglich, weil man die Autorenkorrekturen hat und für Autoren immer Schleifen gemacht werden müssen. Und so lange es über InDesign läuft, funktioniert es nicht vollautomatisiert. Die Automatisierung funktioniert erst hinterher, wenn man elektronische Publikationen beispielsweise E-Books oder Leseproben macht.

Es ist also immer vom Satzsystem und vom Manuskript abhängig. Alternative automatisierte Satzsysteme gibt es: FrameMaker von Adobe, das ursprünglich mal für technische Dokumentationen gedacht war, oder PTCs Arbortext Publishing Engine, was relativ teuer ist

Das Interview wurde am 16. Oktober 2016 telefonisch geführt.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.