Nov 202010
 

This post is also available in: Englisch

Angenommen, Sie haben XML-Daten in ein InDesign-Dokument importiert. Angenommen, das Layout soll den Sinn des Taggings transportieren: Stichwörter kursiv, Eigennamen in Kapitälchen, Zitate eingerückt etc.

Es gibt mehrere Methoden, um das Markup (XML) in Layout umzuwandeln (oder „abzubilden“). Dabei ist es wichtig zu wissen: egal wie Sie es abgebildet haben, sobald die Abbildung erfolgt ist, können sich Layout und zugrundeliegendes Markup völlig unabhängig voneinander entwickeln. Und das ist gefährlich, denn für gebräuchliche XML-Dokumente und bei gebräuchlichen Satzprozessen stellt diese Abbildung eine Einbahnstraße dar, von Markup zu Layout, aber nicht zurück. Wenn Sie sich darauf verlassen, dass nach der Ausführung von Autorkorrekturen alles das, was aussieht wie ein Stichwort, auch ein Stichwort im nachher exportierten XML ist, könnten Sie sich in trügerischer Sicherheit wiegen. Oder die beiden Absätze, die Sie in InDesign sehen, sind in der XML-Struktur nur ein einziger, weil dieser nach dem Import lediglich visuell unterteilt wurde und weil das Markup von dieser Änderung nichts mitbekam.Eine der Hauptmotivationen für XML-first-Workflows ist, dass die Korrektheit des Taggings durch Korrekturlesen eines Renderings (z.B. Print-PDF) überprüft werden kann. Dies basiert auf zwei Annahmen: dass jedes relevante Tagging auf individuelle Weise gerendert (dargestellt) wird und dass allem, das in bestimmter Weise dargestellt wird, ein bestimmtes Tagging zugrundeliegt. Insbesondere der zweite Teil der Annahme wird bei naiv aufgesetzten InDesign-XML-Workflows verletzt.

Stellen Sie sich einen Buchproduktions-Workflow vor, bei dem die Manuskripte in Word normalisiert werden, um anschließend nach InDesign importiert zu werden. Oder Manuskripte werden in einem Online-Editor bearbeitet, als XML gespeichert und dann importiert. Anschließend verfeinert ein Setzer den Umbruch, eine Korrekturfahne geht an den Autor, und die Korrekturen (im PDF oder Ausdruck angezeichnet) werden in InDesign ausgeführt.

Typische Autorkorrekturen:

  1. kursive Wörter steil machen, oder umgekehrt;
  2. Absatz aufteilen oder zwei Absätze zusammenführen, oder neuen Absatz einfügen;
  3. neues Bild mit Legende hinzufügen.

Diese Korrekturen werden gewissenhaft ausgeführt, mit den folgenden Ergebnissen:

  1. Den kursiven Begriffen fehlt das entsprechende XML-Markup;
  2. wenn man die Tags betrachtet, sind die aufgespaltenen Absätze nach wie vor ein einziger;
  3. Bild und Legende fehlen vollständig im XML-Export.

Was läuft da verkehrt? Anscheinend finden Formatierungsänderungen oder neu angelegte Rahmen nicht von selbst ihren Weg in die zugrundeliegenden XML-Strukturen. Das ist so, weil die Abbildung während des Imports stattfindet, in der Richtung XML → Formatierung und nicht andersherum.

Ein Grund dafür ist, dass Layout und Markup (Struktur) zwei unterschiedliche Informationsarten sind, die unabhängig voneinander mit dem Text mitgeführt werden. Die InDesign-Entwickler gingen wohl davon aus, dass im Stadium der typografischen Verschönerung der Inhalt nicht mehr angefasst wird. Deshalb gibt es nicht einmal Warnungen, wenn ungetaggter Inhalt entsteht oder wenn Absatz- bzw. Zeichenformatierung von dem abweichen, was auf Grund des Imports formatiert wurde. Eine Warnung in InDesign könnte so aussehen wie der rosa Hintergrund bei fehlenden Schriften, und es wäre sinnvoll, solche Warnungen bei Abweichung zwischen der aus Tagging resultierenden und der tatsächlich vorgefundenen Formatierung anzuzeigen.

Um den Entwicklern nicht unrecht zu tun: es gibt durchaus einen Weg, um Formatierungen auf Tags abzubilden. Das funktioniert nur für benannte Absatz- und Zeichenformate; soweit ok. Aber diese Abbildungsmöglichkeiten sind so extrem eingeschränkt, dass man damit keine unterschiedlichen Absatztypen, geschweige denn Kästen oder Kapitelhierarchien abbilden kann.  Man kann mit diesen Abbildungsregeln nur triviale XML-Formate erzeugen, die später außerhalb InDesigns in das Ziel-XML umgesetzt werden müssen, z.B., indem man XSTL auf den Export anwendet. Dies wiederum ist beschränkt auf XSLT 1.0, bei dem wichtige Konzepte wie Gruppierung nicht ohne weiteres verfügbar sind, im Unterschied zu XSLT 2.0. Darüber hinaus darf der Setzer nach wie vor Ad-Hoc-Formatierung (also ohne benannte Formatvorlagen) verwenden, so dass der Umbruch den Anschein erweckt, dass sich hinter dem Anschein semantische Information versteckt. Das ist allerdings ohne weitere Vorkehrngen nicht der Fall, weil einfache Kursivierung eben nicht dazu führt, dass im XML ein Keyword-Tag auftaucht. Deshalb sind wir der Ansicht, dass eine solche primitive Abbildung von Formatvorlagen auf Tagging, und überhaupt die ganze Idee, vereinfachtes XML bei der Bearbeitung mitzuführen, obsolet ist. Stattdessen setzen wir auf IDML-Analyse und -Konvertierung des final umbrochenen Dokuments, wie weiter unten ausgeführt.

Aber zurück zum Szenario, in dem Sie bereits zu Anfang das praxisnahe XML eines Artikels auf InDesign-Formatierung abgebildet habenund wo Sie nun anfangen, die Autorkorrketuren einzuarbeiten. Selbst wenn InDesign abweichendes Markup/Layout anmeckern würde, irgendjemand müsste sich darum kümmern, Tagging und Formatierung kohärent zu machen. Und das bedeutet Extra-Arbeit, sprich Extra-Kosten, die mit diesem InDesign-XML-first-Workflow einhergehen. Wir haben es hier zwar nicht mit den gefürchteten doppelten Datensätzen zu tun, wohl aber mit einem Problem teilweise redundanter und separat zu pflegender Huckepack-Informationen, nämlich Markup und Layout, die auf dem (glücklicherweise) nur einfach vorgehaltenen Text existieren.

Was also kann getan werden, um die Extra-Arbeit zu vermeiden? Es gibt grundsätzlich zwei verschiedene Wege: entweder

  • die Workflows ändern, oder
  • Skripting.

Keiner von beiden ist ein Spaziergang.

Anmerkung: das importierte XML in InDesign zu aktualisieren ist keine Option, falls bereits wesentliche Layout-Anpassungen vorgenommen wurden. Nieman möchte den Feinumbruch für 400 Seiten von Anfang an erneut durchführen, nur weil 40 Korrekturen im XML vorgenommen wurden.

Skripten bedeutet hier, Markup automatisch anzupassen, das von der Formatierung abweicht. Dabei gibt es zwei wesentliche Alternativen:

  • InDesign-API-Scripting (Javascript, Applescript, Visual Basic);
  • IDML-Verarbeitung (XSLT 1, XSLT 2 oder externe APIs wie IDMLLib).

Bei beiden Wegen gibt es keine Versicherung, dass das exportierte XML den Änderungen entspricht, die im Proofprozess ausgeführt wurden. Aber Sie können damit typische Sachverhalte korrigieren, wie z. B. ungetaggte Storys / Storys in unverankerten Rahmen, vom Mapping-Ergebnis abweichende Zeichenformatierung, aufgespaltene/verbundene Absätze oder tabulierte Tabellen.

Bei der Entscheidung für InDesign-Skripting oder IDML-Verarbeitung gilt es, zwei wichtige Aspekte zu beachten:  Wartbarkeit und Leistungsfähigkeit (im Sinne akzeptabler Skript-Laufzeit).

Wartbarkeit bedeutet, dass man nicht für jede Dokumentart (identifiziert durch XML-Tags und Formatvorlagen) ein eigenes Autokorrektur-Skript erstellen möchte. Das Skript sollte die tatsächliche Formatierung mit den Abbildungsvorschriften (Tag→Formatvorlage) abgleichen und soviel wie möglich korrigieren, d.h., das Tagging dem vorgefundenen Layout anpassen, wo offensichtlich händische Eingriffe vorgenommen wurden.

Zunächst einmal ist festzustellen, dass es mehrere Abbildungsmethoden gibt. Wir verwenden meistens den aid-Atribut-Ansatz oder IDML-Synthese mit vorausgehender aid-Attribut-Erzeugung. Gerade der letztere Ansatz ist der flexibelste Weg, um mit InDesign Layout aus Markup zu erzeugen. Im Unterschied zu anderen Mapping-Methoden ermöglicht er unter anderem, ohne Rückgriff auf eingebautes Skripting Objektstile zuzuweisen. Und wir bevorzugen die Verarbeitung von IDML-Exporten (mittel XSLT 2) für die Autokorrektur.

Einer der Gründe ist Wartbarkeit: aus der IDML-Datei kann man alle Formatdefinitionen, die konkret angewandte Formatierung und auch die Formatierung auslesen, die ursprünglich beim XML-Import angewandt wurde. Im Falle von Formatierungen, die auf Grund von Autorkorrekturausführung vom ursprünglich Zugewiesenen abweichen, oder auch falls bei neu eingefügten Passagen Tagging generell fehlt, können wir so das adäquate Tagging nachträglich rekonstruieren. Dies alles nur unter Rückgriff auf die Informationen in der IDML-Datei; eine dokumenttypspezifische Anpassung ist i.d.R. nicht nötig. Sollte die Autokorrektur einmal nicht herausfinden können, welches Tagging zu einem bestimmten Textbereich gehört, ergeht eine Warnung an den Setzer.

Hierfür verwenden wir wie gesagt XSLT 2.0. Wir können kein XSLT 1.0 empfehlen, da viele mächtige Konstrukte dort nicht vorhanden sind, was zu aufgeblähten und redundanten Stylesheets führt. Grundsätzlich sind wir der Ansicht, dass für XML-Transformation XSLT die weitaus adäquatere Technologie ist als prozedurale und/oder objektorientierte Sprachen wie Javascript und Java. Deshalb nutzen wir das IDML-Format selbst als API, nicht die prozeduralen/objektorientierten APIs, die InDesign oder IDMLLib bieten.

Aber der wichtigste Grund, InDesigns an sich nicht schlechte API nur sparsam zu verwenden, ist die Leistungsfähigkeit (Performance). Wir haben die IDML-Synthese aus purer Not erstmals angewandt, nachdem wir Stunden darauf gewartet haben, dass InDesign CS4 oder CS5 endlich mit der geskripteten Nachbearbeitung des XML-Imports eines 700-seitigen Buchs fertig wird. Danach konnten wir uns einfach nicht vorstellen, das eingebautes Skripting mit der Aufgabe, 10.000 oder mehr Textbereiche zu prüfen und ggf. autozukorrigieren, in halbwegs akzeptabler Zeit fertig würde.

Wir haben noch nie die IDMLLib ausprobiert. Ich denke, die Performance ist es wohl in einem solchen Maße besser als eingebautes Skripting, wie die Aspose.Words-Bibliothek schneller ist als Words VBA-Skripting. Aspose.Words ist eine Java-Bibliothek, die auf dem .docx-Dateiformat aufsetzt und nicht innerhalb der Word-Applikation läuft, also so wie IDML, und es ist wirklich schnell. Aber auch im .docx-Fall bevorzugen wir XSLT-2-Verarbeitung der Java-Verarbeitung, weil sich Zwischenformat-Stufen, die für die Umsetzung komplexer Transformationen zweckmäßig sind, viel besser in XML modellieren und in XSLT 2 weiterverarbeiten lassen, als es mit Java möglich wäre, wo man sich für jede Zwischenstufe ein neues Objektmodell überlegen müsste. XSLT 2 ist also aus unserer Sicht die wartbarere Variante, was sich nicht zuletzt in kürzerem Programmcode ausdrückt. Wartbarkeit und Performance sind also die Hauptgründe, warum wir IDML-Exporte mit XSLT 2 verarbeiten.

Die Workflows anpassen?

Bisher haben wir uns nur mit externen wie internen Skripting-Lösungen befasst (wobei wir XSLT-Programmierung auch dem Skripting zuordnen). Wie wäre es denn, stattdessen die Workflows zu überdenken?

Wir stellten fest: wenn es keine Autorkorrekturen nach dem Feinumbruch gäbe, müsste man sich keine Sorgen zu machen um Layout, das sich vom importierten Markup fortbewegt.

Ein Weg könnte sein, den Autor alle inhaltlichen Korrekturen ausführen zu lassen, bevor XML erzeugt oder importiert wird, z.B. im Word-Manuskript oder in den XML-Daten eines Content-Management-Systems. Aber die meisten Autoren bestehen darauf, die Texte im finalen Layout zu kontrollieren. Dafür können sie sogar triftige Gründe haben, wie negative Erfahrungen mit Datenkonvertierung zwischen Manuskript und Satzsystem, oder sie brauchen eine zuverlässige Seitenzahlschätzung.

Ein Kompromiss könnte sein, Korrekturfahnen als Grobumbruch zu liefern, also das XML nur zu importieren und höchstens ein paar Skripte darüberlaufen zu lassen, die die Abbildungen geeignet platzieren oder die überlange Textrahmen von Merksätzen u.dgl. zerlegen, damit sie nicht aus dem Satzspiegel herausragen. Ein Autor kann dann fast alle Probleme identifizieren, die zusammenhängen mit fehlenden Stichwörtern oder Bildern, überlangen Absätzen, einer halben Seite Text, die aus Seitenzahlgründen eliminiert werden muss, …

Die Korrekturen werden in den Quelldaten (z.B. Word oder XML) ausgeführt, und erst dann wird der Setzer den Umbruch verfeinern. In den allermeisten Fällen werden diese Layout-Anpassungen keinen Einfluss auf das Tagging haben. Abgesehen von den wohl unvermeidlichen Korrekturen in letzter Minute, die dann in zwei Datensätzen, nämlich in der XML- und in der InDesign-Datei, ausgeführt werden müssen, entfällt hier der Grund für einen Export des XML aus InDesign nach Feinumbruch. Trotzdem ist dies ein valider XML-first-Workflow.

Alle anderen Ausgabeformate wie EPUB (das Sie auf Grund fortbestehender Unzulänglichkeiten nach wie vor nicht in InDesign erzeugen möchten) oder Inhalte für eine Online-Datenbank werden dabei aus demselben qualitätsgesicherten XML erzeugt, das nach InDesign für den Feinumbruch importiert wird, und nicht aus dem XML-Export fragwürdiger inhaltlicher Korrektheit, den gegenwärtig praktizierte naiv konzipierte XML-first- oder Roundtrip-Workflows ausstoßen.

Und wieder Performance

Ein anderer guter Grund für diesen „Grobumbruch-zuerst“-Workflow ist abermals die Performance. Zwei Projekte aus jüngerer Zeit waren aus InDesigns Sicht so groß (> 700 Seiten ohne harten Seitenumbruch, > 300.000 XML-Elemente), dass InDesign einfach nicht fertig wurde mit dem XML-Import. InDesign konnte nicht einmal die entspr. IDML-Datei öffnen, solange sie das mitgeführte XML-Markup enthielt. Deshalb war es mangels importierten XMLs auch keine Option, das XML nach Korrekturausführung wieder zu exportieren, und wir generierten das IDML ohne mitgeführtes XML, um überhaupt einen InDesign-Umbruch aus den XML-Daten hinzubekommen.

Word InDesign XML round-trip workflow
Word-InDesign-XML-Roundtrip-Workflow

Schließlich

Muss es überhaupt XML first sein? Unsere Setzer, die den oben dargestellten XML-first-Workflow für relativ einfach strukturierte Belletristik-Titel umsetzen mussten, war sehr unglücklich mit all dem Kommunikations-Overhead dieses arbeitsteiligen Workflows. Anstatt dass die InDesign-Abteilung das Word-Mansukript klassischerweise in InDesign importiert und dort mit Formatvorlagen ausstattet, musste die Word-Abteilung die Word-Dateien normalisieren und die XSLT-Abteilung dieses Word nach DocBook mit aid-Attributen konvertieren. Wenn der Setzer Auszeichnungs- oder Konvertierungsfehler entdeckt hat, musste er abwägen, ob er es punktuell im importierten XML  und im Layout anpasst, oder ob er bei einem grundsätzlichen Fehler die gesamte Prozesskette wieder von vorne anstößt. Schließlich haben sie sich einen Workflow gewünscht, bei dem in InDesign konsistent mit Formatvorlagen ausgezeichnet wird und anschließend aus dem IDML-Export das XML erzeugt wird. Und ich glaube, angesichts der Heterogenität der Eingangsdaten und des hohen Normalisierungsgrades, den sie in InDesign erzielen, könnte das ein adäquaterer und vor allem wesentlich kostengünstigerer Workflow sein. Im Grunde ist es derselbe Workflow, der auch zum Einsatz kommt, wenn im IDML-Export das Tagging heuristisch gemäß der vorhandenen Formatierung korrigiert wird, mit der Randbedingung, dass anfangs überhaupt noch kein Tagging vorhanden ist.

In einem solchen Workflow ist es von entscheidender Bedeutung, dass die Setzer nur akeptierte benannte Formate und akzeptierte manuelle Formatierungen verwenden. Die Einhaltung dieser Konventionen kann von einem entsprechend konfigurierten XSLT-2-Autokorrektur-Stylesheet, von separaten Schematron-Regeln oder von einem hierfür erstellten IDMLLib-Programm überwacht werden. Solche Datenprüfungsroutinen, die Manuskript- oder Satzdaten in Bezug auf Strukturierbarkeit prüfen, sind Gegenstand eines eigenen Artikels.

Schließlich schließlich, muss es überhaupt InDesign sein? In alternativen Satzsystemen wie LaTeX, XSL-FO, 3B2 oder anderen Werksatzsystemen lassen sich viele Umbruchfeinheiten per Processing Instructions (PIs) beeinflussen. In LaTeX (d.h., xmltex) und XSL-FO gibt es gar keine andere Schnittstelle als PIs, um individuelle Layoutanweisungen durchzustellen. Das bedeutet, weil die XML-Datei die einzige Quelle für punktuelle Layout-Manipulationen ist, können sich Markup und Layout nicht so leicht separat entwickeln.  Andererseits besteht z.B. in xmltex oder 3B2 die Möglichkeit, alles mögliche in PIs zu verpacken und am normalen Tagging vorbei zu rendern, bis hin dazu, das komplette zu rendernde Dokument in eine PI zu stecken. Ein EPUB-Renderer würde dann irgendwelchen anderen Inhalt anzeigen als den, der im PDF steht. Solche semikriminellen Verstöße sind jedoch nicht auf xmltex oder 3B2 beschränkt, sondern sie kommen in abgewandelter Form auch in InDesign vor. Aus unserer Sicht kann man sie nur unterbinden, wenn man ein Rendering, das aus reinem XML (ohne PIs bzw. wie von InDesign exportiert) erzeugt wurde, gegen das jeweilige Print-Rendering visuell vergleicht.

Warum muss es also so oft InDesign sein? Die Werke, um die es hier geht, erfordern selten die ganze Palette von Layout-Individualisierungen, wie InDesign sie bietet. Insofern wären die Verlage mit einem klassischen XML-fähigen Werksatzsystem sehr gut bedient. Und es sollte ja nicht so wichtig sein, mit welchem Renderer ein Output erzeugt wurde, Hauptsache, es stehen genügend Dienstleister für das jeweilige Satzsystem zur Verfügung.

Ich vermute, die aktuelle Präferenz für InDesign bei vielen Herstellungsleitern ist ein kulturelles Phänomen, so wie für viele Leute Textverarbeitung lange Zeit synonym mit MS Word war.

  2 Responses to “XML-first-Workflows in InDesign: trügerische Sicherheit?”

  1. danke für den artikel. wenn man sich gerade überlegt, bzw. vom chef überlegt wird, von xml:fo nach idml zu gehen sieht man schonmal erste hürden und ängste 😉

  2. […] Zum Problem von Autorenkorrekturen bei mitgeführtem XML möchte ich auch gerne den Artikel XML-first-Workflows in InDesign: trügerische Sicherheit? von Gerrit Imsieke empfehlen. Der Beitrag ist zwar schon fast fünf Jahre alt, aber dank Adobes […]

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)