XML-Know How

Von den Satzdaten zu Textdaten

Es ist in aller Regel nicht die Masse, die Kosten bei der Konvertierung verursacht, sondern die Komplexität und Inkonsistenzen des Datenbestandes.

Die erste Hürde sind die Satzdaten selbst. Um diese nach XML konvertieren zu können, müssen sie in einem irgendwie vorstrukturierten Textformat vorliegen, so dass der Konvertierer erkennen kann, welcher Text Überschrift, welcher Absatz und welcher Anmerkung usw. ist. Das gilt gleichermaßen für die rein manuelle Konvertierung wie für die automatische mittels eines Konvertierungsskriptes.

Satzdaten aus DTP-Programmen automatisiert in eine solche Textform zu bringen, ist nur bei sehr einfachen Texten und neueren DTP-Programmen möglich. Liegt ein einfacher belletristischer Text vor, in dem neben Absätzen allenfalls Kapitelüberschriften vorkommen, dann kann der Export in ein weiterverarbeitbares Format gelingen. Sind z. B. die Überschriften nach dem Export noch vom Text abgesetzt und durch bestimmte Merkmale eindeutig identifizierbar (z. B. als Absatz ohne Satzendzeichen), genügt anschließend ein kurzes Skript, um die Textdatei in XML zu verwandeln. Bei komplexeren Seiten ist eine konsequente Verwendung von Stilvorlagen im DTP-Programm unbedingte Voraussetzung, um überhaupt einen sinnvollen Datenexport vornehmen zu können, der dann mit Skripten, die oft erst programmiert werden müssen, weiterverarbeitet werden kann.

Dabei gilt: Je komplexer der Seitenaufbau, um so schwerer ist es, aus den Satzdaten einen automatisch verwertbaren, fortlaufenden Text zu erhalten. Leider sieht man dem Ergebnis des Satzbildes nicht an, wie es erzielt worden ist: bei layoutorientierten Systemen kommt man in der Regel mit vielen Wegen zum gleichen Layout-Resultat. Daher sind solche Daten meist sehr inkonsistent. Das ist besonders bei Werken der Fall, die schon in mehreren Auflagen produziert wurden, so dass verschiedene Setzer mit ihren individuellen Vorlieben ihre Spuren in den Satzdaten hinterlassen haben. Wurden Stilvorlagen aber nicht konsequent und einheitlich angewendet, bleibt mitunter nur das aufwändige manuelle Kopieren aus den Satzdaten in einen XML-Editor (»Copy–Paste«).

Auch die automatische Umwandlung von Layout-Markierungen in inhaltliche ist meist selbst dann anspruchsvoll, wenn die Kodierungen einheitlich sind. Wurden aber für ein und dasselbe Layout-Resultat diverse Wege und damit Kodierungen verwendet, steigt der Aufwand exponentiell an. Denn das Konvertierungsskript muss jede Kodierungsvariante vorsehen.

Leider ist meist vor Beginn der Konvertierung nicht klar, wie groß die Inkonsistenz ist. In der Praxis wird für die Preisfindung von Testdaten ausgegangen, etwa den ersten zwanzig Seiten eines Werkes, bei komplexeren Werken auch von Ausschnitten der schwierigsten Passagen. Diese Testpassagen sind wegen ihres geringen Umfangs oder weil sie speziell als Testdaten erstellt wurden oft überdurchschnittlich homogen, so dass der Konvertierer von relativ wenigen Kodierungsvarianten und damit einem einfachen Skript ausgeht. Die übrigen, weit umfangreicheren Echtdaten enthalten aber allzu oft viele weitere Varianten dieser Kodierungen.

Und weil, zumal bei jahrelang gewachsenen Werken, meist niemand diese Kodierungen dokumentiert hat (es interessierte ja immer nur der korrekte Ausdruck), kann keiner absehen, wie groß der Aufwand der Konvertierung tatsächlich sein wird. Aus prinzipiellen Gründen lässt sich der Grad der Inkonsistenz nicht automatisch feststellen, da ja gerade die Inkonsistenz der Kodierungen verhindert, dass Analyseprogramme zuverlässige Aufsatzpunkte finden.

In der Praxis bedeutet das, dass das Konvertierungsskript schnell um ein Vielfaches aufwändiger werden kann als ursprünglich geplant. Die Kosten der automatischen Konvertierung wachsen entsprechend und können schnell einer manuellen Konvertierung gleichkommen.

In gewisser Weise handelt es sich hier um einen Teufelskreis: um entscheiden zu können, ob automatische oder manuelle Konvertierung kostengünstiger ist, müsste man das Werk erst so gründlich analysieren, dass der Analyseaufwand dem für die automatische Konvertierung entspricht.

All das kann im schlimmsten Fall heißen, nach entsprechendem Analyseergebnis gar nicht auf die Satzdaten zurückzugreifen, sondern eine Redigitalisierung des gedruckten Werkes vorzunehmen. Das kann auch dann notwendig sein, wenn die Satzdaten zwar konvertierbar sind, aber nicht den letzten Stand der Bearbeitung repräsentieren, weil etwa letzte Korrekturen nicht im Gesamtdatenbestand, sondern in eigenen, kleinen Dateien vorgenommen wurden, um einen labilen Umbruch nicht zu gefährden. Ein solches Vorgehen war früher üblich – es sollte heute der Vergangenheit angehören. Leider zeigt die Erfahrung, dass häufig immer noch nach dem Prinzip des »digitalen Klebeumbruchs« gearbeitet wird. Wenn die Satzdaten nicht auf dem imprimierten Stand sind und auch nicht mehr auf diesen Stand gebracht werden können, ist der Aufwand für das nachträgliche Korrekturlesen und Korrigieren häufig höher als die Neuerfassung.

Redigitalisierung heißt: Einscannen oder Erfassen lassen. Beim Scannen wird der Text zunächst als Grafik abgespeichert und anschließend per OCR (optical character recognition, optische Zeichenerkennung) in einzelne Zeichen aufgelöst, die zusammengesetzt wieder den Text ergeben. Scannen kommt nur bei einfacherem Seitenaufbau und hoher Druckqualität in Frage. Mehrfachscans, automatische Textvergleiche der Mehrfachscans und Rechtschreibprogramme helfen, den Text fehlerfrei zu bekommen.

Bei komplexeren Werken hilft meist nur eine manuelle Erfassung mit Vorstrukturierung: Das Werk wird mehrfach erfasst (double oder triple keying), durch automatischen Textvergleich der Versionen und Rechtschreibprogramme werden Fehler erkannt und korrigiert. Die Erfassungskräfte arbeiten nach Regeln, nach denen sie bestimmte Textteile durch bestimmte Marken im Text (Kürzel aus Sonderzeichen) kennzeichnen. Diese Marken können dann durch Konvertierungsskripte ausgewertet und so das XML erzeugt werden.

Voraussetzung dafür ist, dass zuvor für die Erfassung Schreibanweisungen entwickelt werden müssen, die die Textstruktur eindeutig kennzeichnen und die der Konvertierung entgegenkommen. Auch die Konvertierungsskripte müssen geschrieben werden. Dazu sollte, wie schon erwähnt, idealer Weise bereits eine verwertungsorientierte DTD vorliegen.

Viel besser sieht es aus, wenn Sie Satzdaten aus einem Werksatzsystem haben, in dem die Daten (Texte und Steueranweisungen) schon als Textdaten vorliegen, wie z. B. in 3B2, PowerPublisher, TeX oder TUSTEP. Dann wird ein Export der Daten problemlos möglich sein. Noch besser, wenn in diesen Systemen mit einheitlichen Styles gearbeitet worden ist – dann ist auch die Konvertierung der exportierten Daten automatisierbar. Am besten, wenn diese Styles dabei nicht layout- sondern inhaltsorientiert waren. Dann steht Ihnen sofort ein Text mit Markierungen zur Verfügung, aus dem ohne weitere Probleme XML mit semantischem Markup erzeugt werden kann.