idml2xml: Verbesserungen
bei geschachtelten Formaten

Altes Verfahren

Bisher lief die Verarbeitung geschachtelter Formate in 4 Schritten:

1. Split-Punkt-Kandidaten ermitteln (Zeichenpositionen in Textknoten, bis zu denen ein ZF angewandt werden könnte – z.B. alle Tabs oder alle Doppelpunkte, falls die Instruktion sagt, bis zum 3. Doppelpunkt ZF XY anzuwenden)
2. Diese Kandidaten aus eventuell umgebendem Markup (explizite Formatzuweisungen, Tiefstellungen, Links, …) herausziehen, so dass sie unmittelbar unter dem Absatz-Element stehen
3. Ggf. neues ZF-Tagging einbringen (z.B. bis zum 3. Doppelpunkt-Split-Kandidaten alles in einen span mit ZF XY packen
4. Bereiche mit gleichem ZF wieder zusammenführen, dabei auch die ungenutzten Split-Kandidaten mit einschließen

Defizite:

• Die Splitpunkt-Kandidaten für Initialen, für String-Separatoren wie Doppelpunkt und Halbgeviert oder auch für Instruktionen wie „ZF auf die ersten 2 Wörter anwenden“ werden per Regex (aus den Instruktionen generiert) identifiziert
• Die Regexes werden allerdings nur innerhalb von Textknoten angewandt. Bei vorhandenem Markup innerhalb eines Absatzes – explizit zugewiesene Formatvorlagen oder Ad-hoc-Formatierung, Tiefstellungen, Links oder eingestreuten Indexbegriffen und Fußnoten – muss eigentlich Text mitanalysiert werden, der sich über Markupgrenzen erstreckt bzw. der Indexbegriffe oder Fußnotentext ignoriert. Andernfalls werden Splitpunktkandidaten nicht oder falsch ermittelt
• Der 2. Schritt (Splitpunktkandidaten hochziehen) kann bei komplexen Instruktionen / langen Texten lange dauern

Sowohl beim Suhrkamp-Problem als auch beim Hogrefe-Problem konnten die regulären Ausdrücke wegen vorhandenen Markups keinen Splitpunkt-Kandidaten finden, weswegen im Konvertierungsergebnis bei Suhrkamp der ganze Absatz fett war und bei Hogrefe der ganze Absatz aus Initialen bestand.

Das Suhrkamp-Problem konnte die Kollegin Schmalfuß lösen, indem sie Zeichenbereiche mit dem speziellen ZF No character style auflöste.

Für eine allgemeine Lösung muss man wie gesagt im vorliegenden Textknoten die Inhalte anderer Textknoten desselben Absatzes berücksichtigen.

XSLT 3: Akkumulatoren

Normalerweise hat man bei XSLT während der Verarbeitung keinen Zugriff auf das bisherige Verarbeitungsergebnis. Aus diesem Grund laufen komplexere Verarbeitungen oft in mehreren Durchläufen, in denen Zwischenergebnisse im transformierten Dokument gespeichert werden, z.B. bei welcher Zeichenposition innerhalb des Absatzes ein Textknoten beginnt.

Die xsl:accumulator-Instruktion bietet genau diesen Zugriff während der Verarbeitung: Man kann mitzählen, bei welcher Zeichenposition man ist, man kann aber auch komplexere Strukturen wie die aktuell aktive NestedStyle-Instruktion und den noch nicht von bisherigen Instruktionen abgedeckten markup-unabhängigen Text mitführen und -berechnen.

Zu diesem Zweck kann man sich beliebige Akkumulatoren definieren, indem man ihnen einen Namen gibt und die Berechnungsvorschriften dafür spezifiziert, wie der Wert des Akkumulators sich ändert, wenn während der Dokument­verarbeitung ein Knoten betreten bzw. verlassen wird.

Das bietet drei Vorteile:

• „Korrektere“ und unaufwändige Berechnung der Position von Splitpunkt-Kandidaten
• Der Absatz muss nicht zerhackt werden, damit jeder Splitpunkt-Kandidat unmittelbar unterhalb des Absatzes liegt, sondern es genügt, z.B. nur den 3. Doppelpunkt im Textknoten, in dem der 3. Doppelpunkt steht, mit einem Tag zu umgeben.
• Dann muss man auch nicht mehr die zerhackten Absatzbestandteile zusammenführen.

Für die beiden letzten Punkte gäbe es auch Möglichkeiten, sie mit XSLT 2 ohne Zerhacken des Absatzes zu gestalten. Der erste Punkt aber bleibt, und diese unaufwändige und textknotenübergreifende Methode, in einem Durchlauf die Kandidaten zu ermitteln und nur die tatsächlich wirksamen (z.B. 3. Doppelpunkt) zu taggen, geht in XSLT nur mit Akkumulatoren.

Der Akkumulator nested-style-instruction (Ausschnitt)