Schema ST4 Dokumente vollautomatisch optimal publizieren

Bei der Einführung eines Redaktionssystems für technische Dokumentation liegt der Schwerpunkt meist auf der Erfassung, Strukturierung und nachhaltigen Pflege medienneutraler, mehrsprachiger Inhalte für komplexe technische Zusammenhänge.

Die Publikation der Inhalte in unterschiedlichen Medien soll möglichst vollautomatisch basierend auf dem aktuell freigegebenen Datenstand in den einzelnen Sprachen erfolgen.

Bei der Publikation von Print-Dokumenten ergibt sich meist das übliche Dilemma: bei vollautomatischer Erzeugung müssen Abstriche bei Corporate Design, Layout und Gestaltung gemacht werden; will man anspruchsvolle Ideen zur Gestaltung umsetzen, dann müssen Dokumente nachbearbeitet werden, und man verliert die Vorteile vollautomatischer Erzeugung in beliebig vielen Sprachen.

Bei der Siegenia-Aubi KG, Hersteller moderner Systeme rund um Fenster-, Türen- und Komfort-Lösungen mit Sitz in Wilnsdorf, ist man seit über 10 Jahren die vollautomatische, optimierte Publikation von Datenblättern mit DocScape gewohnt.

Daten werden aus SAP exportiert, vollautomatisch aufbereitet und gemäß Corporate Design Vorgaben zu Datenblättern mit optimalem Seitenlayout gestaltet.

Bei der Einführung des Redaktionssystems Schema ST4 für die technische Dokumentation wurde schnell klar, dass die gewohnte Layout-Qualität von Print-Dokumenten bei vollautomatischer Dokumenterzeugung mit „Bordmitteln“ nicht würde erreicht werden können.

Insofern wurde der Weg eingeschlagen, Schema ST4 als Datenquelle mit dem bestehenden DocScape-System für das  vollautomatische, optimierte Print-Publishing zu verbinden.

Hierdurch wurde eine best of breed Lösung geschaffen, welche sowohl für den Redaktions- als auch für den Print-Publishing-Prozess optimale Leistung erzielt.

Case Study zum Einsatz von Schema ST4 mit DocScape

Fazit der Case Study

Highlights der DocScape-Umsetzung

Für die Anbindung von Schema ST4 an DocScape sind keine zusätzlichen Anpassungen oder Plugins des Redaktionssystems vonnöten.

Stattdessen wird ein Standard-Export-Format „04_uniqueids“ von Schema ST4 gelesen und verarbeitet.

Alle für die Dokumenterzeugung benötigten Inhalte und Informationen können diesem Export entnommen werden, insbesondere

1. Textformatierung, Tabellen und eingebettete Bilder.
2. Dokumentstruktur zur Einteilung in Kapitel und Abschnitte und Erzeugung von Verzeichnissen, inkl. spezieller Metadaten, z.B. über eingebettete Subdokumente.
3. Metadaten für Titeleite sowie Kopf- und Fußbereich.
4. Metadaten, die die Darstellung beeinflussen, z.B. Art der Bindung, Zusatzinformationen zur Ausgabe von Grafiken oder Tabellen, Ausgabe der Titelseite ja/nein usw.

Die Vorgabe für das Seitenlayout sieht normalerweise eine zweispaltige Darstellung vor, die nur auf volle Breite „umgeschaltet“ wird, wenn die Inhalte für die zweispaltige Darstellung zu breit werden.

Wenn Inhalte im Redaktionssystem erfasst werden, ist insbesondere bei Tabellen kaum abzuschätzen, ob ein Element zu breit ist oder nicht.

Daher werden Inhalte, besonders Tabellen, durch DocScape automatisch abgemessen, um zu bestimmen in welcher Breite sie dargestellt werden sollten.

Insgesamt übernimmt das Regelwerk bei der Spalteneinteilung folgende Aufgaben:

1. Breite der Inhalte bestimmen und Inhalte gleicher Breite gruppieren.
2. Inhalte in zwei- oder einspaltiger Darstellung ausgeben. Nach Bedarf Wechsel der Darstellung mehrfach pro Seite.
3. „Austreiben“ der Inhalte auf die jeweilige Breite.
4. Automatischer Umbruch und Ausgleich der Spalten.
5. Seitenumbruch automatisch an günstigen Stellen.

Eine Herausforderung bei der automatischen Erstellung der technischen Kataloge sind die vielen Seiten, auf denen die konkrete Anordnung von Beschlagteilen im jeweiligen Fenster- oder Türrahmen gezeigt wird.

Diese Seiten bestehen aus einem Grafikelement mit einem großen Leerraum in der Mitte, in dem Piktogramme, Tabellen und Texte platziert werden.

Im Redaktionssystem wird der jeweilige Abschnitt einfach als Grafik gefolgt von den Textinhalten angelegt, mit einem Meta-Attribut, das signalisiert, dass es sich um eine Rahmengrafik handelt.

DocScape ordnet dann die Inhalte automatisch folgendermaßen an:

1. Seitenfüllende Ausgabe der Rahmengrafik.
2. Bestimmung der Größe und Position des in der Grafik vorhandenen Leerraums.
3. Formatierung und mittige Positionierung der Textinhalte im vorhandenen Leerraum.
4. Um sicherzustellen, dass alles passt, darf der Textinhalt innerhalb vorgegebener Grenzen automatisch „skaliert“ werden (Schriftgröße und Abstände).
5. Kann der Inhalt mit der minimalen Skalierung nicht im Leerraum platziert werden, so wird automatisch ein Seitenumbruch eingefügt und die Rahmengrafik wird auf der/den Folgeseiten wiederholt.

Da die Rahmengrafik sehr unterschiedlich geformt sein kann, muss die Weißraumberechnung, Skalierung und Positionierung für jede Seite individuell erfolgen.

Die Animation zeigt, wie die Inhalte auf den Rahmenseiten platziert werden. Dargestellt wird eine Debugging-Ansicht, bei der die Rastereinteilung der Seite sowie die Belegung der Rasterzellen markiert wird (leere Rasterzellen werden Gelb gefärbt).

Die Ausgabe der Inhalte erfolgt in folgenden Schritten:

1. Rahmengrafik auf der Seite platzieren. Es ist zu erkennen, dass die Rasterzellen in der Mitte der Grafik leer bleiben.
2. Die innen zu platzierenden Inhalte werden zunächst auf „virtuellen Seiten“ (auf der rechten Seite dargestellt) formatiert und abgemessen. Dabei werden nach Bedarf verschiedene Schriftgrößen ausprobiert.
3. Falls der Textinhalt auch bei verringerter Schriftgröße nicht in den Leerraum passt, wird ein Seitenumbruch ausgelöst und die Rahmengrafik auf allen betreffenden Seiten wiederholt.

Bei den vielen komplexen Tabellen, die in verschiedenen Sprachen erstellt werden, ist es sehr wichtig, keine Spaltenbreiten vorgeben zu müssen.

Dies würde unweigerlich erheblichen Pflege- und Nachbearbeitungsaufwand nach sich ziehen.

Die in den Tabellen abgebildeten technischen Daten bezieht das Redaktionssystem vom verknüpften PIM; die Tabelleninhalte sind also einer großen Dynamik und ständigen Veränderungen unterworfen.

Daher werden die Breiten der Tabellenspalten stets automatisch aufgrund der in den Spalten enthaltenen Inhalte berechnet.

Die Abbildung zeigt die gleiche Tabelle in verschiedenen Sprachen. Unterschiedliche Textlauflängen in der Produktbezeichnung bewirken unterschiedliche Spaltenbreiten.

Eine Vorgabe für die Dokumenterstellung ist, dass in sehr umfangreichen Tabellen die Schrift verkleinert werden darf, um Umbrüche zu minimieren.

Dabei sollen sowohl Seitenumbrüche in einer Tabelle als auch

Zeilenumbrüche in Tabellenzellen möglichst vermieden werden.

Erreicht wird das dadurch, dass eine Tabelle in mehreren Schriftgrößen formatiert wird. Dabei wird gemessen, ob

• die Tabelle ganz auf die Seite passt;
• sich durch die Schriftgrößenänderung wesentliche Änderungen an den Zeilenumbrüchen innerhalb der Tabelle ergeben haben.

Aufgrund dieser Kriterien wird dann die „optimale“ Schriftgröße ermittelt und die Tabelle in dieser ausgegeben.

Die Animation zeigt, wie Tabellen während der Verarbeitung mehrfach formatiert werden, um die optimale Schriftgröße zu bestimmen, bis schließlich die Ausgabe in der ermittelten optimalen Schriftgröße erfolgt.

Im Bild unten sind noch einmal die Tabellendarstellung in der normalen Schriftgröße sowie in der letztlich gewählten optimalen Schriftgröße gegenüber gestellt.

Man erkennt, dass viele Zeilenumbrüche in Tabellenzellen vermieden werden konnten.

Ein DocScape-Regelwerk, das komplexe Darstellungs- und Optimierungsaufgaben erfüllt, ist modular aufgebaut und enthält diverse Regeln auf verschiedenen Abstraktionsebenen, die bei der Dokumenterzeugung ineinandergreifen.

Eine Herausforderung bei der Pflege und Weiterentwicklung eines solchen Regelwerks besteht darin, dass Änderungen zur Verbesserung der Ausgabe an einer bestimmten Stelle sich potentiell an vielen anderen Stellen in unterschiedlichen Dokumenten auswirken können.

In den meisten Fällen ist dies erwünscht (zur Verbesserung der Darstellung), aber wie können unerwünschte Nebenwirkungen einer Änderung entdeckt werden?

Hier kommt der Regressionstest ins Spiel.

1. Referenzdokumente werden als Quelldaten sowie als formatiertes Dokument hinterlegt.
2. Nach jeder Änderung am System werden automatisch die betreffenden Dokumente neu erzeugt und mit den hinterlegten Referenzdokumenten verglichen.
3. Ein Testbericht mit allen Seiten, auf denen es Unterschiede gegeben hat, wird erstellt. Dabei werden die Unterschiede klar auf einer separaten Ebene markiert.

So kann nach jeder Anpassung am Regelwerk ohne Mühe geprüft werden, ob es zu unerwünschen Nebenwirkungen der Änderung gekommen ist.