XML und InDesign I – Tücken des XML-Imports

InDesign war ursprünglich nur als reines DTP-Programm konzipiert. Unter dem Eindruck des XML-Hypes Anfang der 2000er versah Adobe seine Software mit Funktionen zur Verarbeitung von XML-Daten. Für Verlage und Satzdienstleister klang die Lösung zunächst vielversprechend: Ohne XML-Editor und Programmieren lässt sich das XML in InDesign importieren, im Hintergrund mitführen und nach dem Satz inklusive Korrekturen einfach wieder herausspielen.

InDesign schien nun auch für „XML-First“-Workflows geeignet und versprach gleichzeitig die Produktion von anspruchsvollen Layouts und sauberen XML-Daten. In der Praxis weist InDesigns XML-Import allerdings zahlreiche Löcher auf, die mit Skripten gestopft werden müssen. Der Satz mit XML ist umständlich, erfordert viele händische Eingriffe und ist dadurch fehleranfällig. Dennoch möchte man in Verlagen weder auf InDesign noch auf XML verzichten. Der folgende Artikel ist Teil einer kleinen Serie über InDesign und XML und rückt zum Anfang die XML-Import-Funktion in den Fokus.

Absatz- und Zeichenformate

Der Import von XML funktioniert bei InDesign über die Zuordnung von XML-Elementen zu Formatvorlagen. Dafür sieht InDesign mehrere Wege vor. Der vielleicht bekanntere Weg ist die Verwendung des Menüs Formate zu Tags zuordnen aus der Strukturansicht. Darin ordnet man dem Namen einer Formatvorlage den Namen eines XML-Elements zu.

Diese Methode setzt voraus, dass ein Element immer einer Formatvorlage zugeordnet werden kann. Ein XML-Element kann aber in verschiedenen Kontexten eine andere Bedeutung annehmen. Bei DocBook repräsentiert das Element title eine Überschrift oder eine Bildunterschrift – je nachdem ob dessen Elternelement chapter oder figure heißt. Bei TEI würde dasselbe Problem mit Überschriften entstehen, die unabhängig von ihrer Ebene alle mit dem head-Element ausgezeichnet werden.

Für das Mapping von XML auf Formatvorlagen geht man daher meistens einen anderen Weg. Dabei reichert man das XML mit InDesign-spezifischen Attributen an. XML-Elemente lassen sich bestimmten Absatz- und Zeichenformaten zuordnen, indem man sie mit aid:pstyle und aid:cstyle auszeichnet:

<para xmlns:aid="http://ns.adobe.com/AdobeInDesign/4.0/" 
  aid:pstyle="absatz">Preheat the oven to 
  <emphasis aid:cstyle="kursiv">220 C / Gas 7</emphasis> … 
</para>

Die Attribute müssen den XML-Namespace http://ns.adobe.com/AdobeInDesign/4.0/ verwenden, der mit dem Präfix aid verknüpft ist. Die Verwendung von XML-Namespaces ist hier eigentlich eine gute Sache. Durch die unterschiedlichen Präfixe, kann man die InDesign-spezifischen Attribute leicht vom Rest der XML-Daten unterscheiden. Allerdings führt InDesign diesen Ansatz nicht konsequent fort, wie sich am Beispiel von Bildverknüpfungen zeigt.

Bildreferenzen

InDesign setzt voraus, dass eine Bildverknüpfung immer mit einem href-Attribut angegeben wird. Verwendet das XML-Schema nicht zufällig schon das href-Attribut für Bildreferenzen, muss man es z. B. via XSLT umbenennen.

Der Bildimport funktioniert ironischerweise nicht, wenn das Attribut mit aid-Namespace-Präfix ausgezeichnet ist. Damit InDesign eine Bildverknüpfung auch als solche anerkennt, darf das href-Attribut keinen Namespace-Präfix tragen. Ein Attribut mit aid-Namespace wäre aber wünschenswert, um es von identisch benannten Attributen im Quell-XML zu unterscheiden. Solche Kollisionen können entstehen, wenn das XML-Schema das href-Attribut nicht für Bildreferenzen vorsieht. Ein href-Attribut kann auch andere Dateiverweise repräsentieren, etwa auf Zusatzmaterial. In dem konstruierten Beispiel unten würde InDesign versuchen das PDF als Bild zu laden, gleichwohl es eine externe Referenz auf einen Artikel repräsentiert.

<SupplementaryMaterial href="article.pdf" page="12"/>

Tabellenmodell

Um XML-Tabellen zu importieren, müssen diese im CALS- oder InDesign-Tabellenmodell vorliegen. Bei Schemas wie TEI, NLM (ohne OASIS-Tables-Erweiterung) und XHTML muss man die Tabellen also vorher in eines der beiden vorgegebenen Schemas konvertieren.

Das InDesign-Tabellenmodell unterscheidet sich von gängigen XML-Tabellenmodellen, indem es auf Elemente für Zeilen verzichtet und nur solche für Zellen und die Tabelle selbst vorsieht. Die Anzahl der Kolumnen, Zellenbreiten und das Überspannen von Zellen können mit aid-Attributen gesteuert werden. Die Namen der Elemente spielen für InDesign hier übrigens keine Rolle, solange eine bestimmte Struktur eingehalten wird:

You can use different names for the tags, but all of your tables must match that basic structure …*

<?xml version="1.0" encoding="UTF-8"?>
<root  xmlns:aid="http://ns.adobe.com/AdobeInDesign/4.0/">
  <foo aid:table="table" aid:trows="2" aid:tcols="2">
    <bar aid:table="cell" aid:ccolwidth="40">a1</bar>
    <bar aid:table="cell" aid:ccolwidth="60">a2</bar>
    <bar aid:table="cell" aid:ccols="2">b1</bar>
  </foo>
</root>

Weißraum und Umbrüche

Unglücklich ist auch die Übernahme von Weißraum beim XML-Import gelöst. Zum Weißraum zählt InDesign alle Leerzeichen, Tabulatoren und Umbruchzeichen, die zwischen Elementen stehen. Steuern kann man deren Übernahme über die Option Inhalte von Elementen, die nur Leerraum enthalten, nicht importieren.

Damit lässt sich aber nur steuern, ob InDesign blind Weißraum und alle Umbrüche übernimmt oder verwirft. XML-Code wird aber häufig entweder in einer Zeile oder zur besseren Lesbarkeit eingerückt mit Umbrüchen versehen, wie das folgende Beispiel zeigt.

<?xml version="1.0" encoding="UTF-8"?>
<article>
<para>1. Element ohne Einrückung</para>
  <para>2. Element eingerückt</para><para>3. Element ohne Umbruch</para>
</article>

Obwohl man meinen könnte, InDesign kenne über die Formatzuordnung alle Elemente, die einen Absatz repräsentieren, muss man das XML-Dokument so vorbereiten, dass es die richtigen Umbrüche aufweist und alle Einrückungen entfernen.

Ohne vorgelagerte Konvertierung ist ein XML-Import in InDesign nicht zu haben. Die in XML importierten Daten entsprechen also nicht mehr dem ursprünglichen XML-Schema. Dieser Punkt ist insofern wichtig, als dass man nach dem Export aus InDesign die Daten wieder „in Form“ bringen muss. Eine nachträgliche Konvertierung ist Voraussetzung, um die Daten wieder in Einklang mit dem XML-Schema zu bringen.

Fußnoten, Querverweise, Rahmen etc.

Eine Vorkonvertierung vermag aber längst nicht alle Probleme zu lösen. Elementare Dinge wie Fußnoten, Querverweise, Indexeinträge und Hyperlinks werden von InDesigns XML-Import nicht unterstützt. Ebenso wenig lassen sich verankerte Rahmen, wie sie für Marginalien oder für aus dem Textfluss herausgelöste Bilder und Tabellen benötigt werden, während des XML-Imports anlegen. Damit deckt der XML-Import nur Titel mit einer sehr einfachen Struktur ab.

Wer auf XML-Import setzt, muss sich mit Workarounds behelfen. Workaround heißt hier die Entwicklung eines Skriptes bzw. eher einer Skriptbibliothek, welche die fehlenden Funktionen über InDesigns Skript-Schnittstelle nachrüstet. Der nächste Beitrag ist daher dem Einsatz von Skripten beim Satz mit InDesign und XML gewidmet.