XML-Workflows in InDesign

Gerrit Imsieke von le-tex hat unter XML-first Workflows in InDesign: Ropes of Sand? eine lesenswerte Zusammenfassung über mögliche Herangehensweisen von strukturierten Daten und InDesign geschrieben.

Er favorisiert letztlich die in meinem tekom-Vortrag unter Datenextraktion vorgestellte Lösung:

Er legt sich allerdings auf eine IDML-Lösung fest, während ich momentan oftmals eine Skripting-Lösung bevorzuge. Ein Vorteil beim Skripting ist, dass man die Qualitätssicherung innerhalb von InDesign interaktiv mit den Anwendern durchführen kann. Ein Nachteil ist sicherlich die Geschwindigkeit – vor allem wen man versucht pseudo intelligent verschiedene Situationen fürs XML zu »erraten«.

Unabhängig von Skripting oder IDML: Dieser Ansatz hat immer den Nachteil, dass der Anwender zunächst in seiner klassischen Arbeitsweise beliebig sinnfreie InDesign-Dokumente erstellen kann. Diese sehen vielleicht im Druck noch gut aus, sind aber für strukturierte Daten ungeeignet. Eine Datenextraktion erfordert immer die Arbeit nach festgelegten Konventionen und Vorgehensweisen, so dass die automatisierte Auswertung gelingen kann.

Auch wenn ich kein Freund von XML-First-Workflows bin, hat man hier die Möglichkeit über die Einführung einer neuen Technologie neue Arbeitsweisen und Konventionen einzuführen. Beim »weiter so« ist dies nur schwer zu vermitteln. Zusätzlich bietet sich die Möglichkeit, die Produkte zu standardisieren und sich von rätselhaft begründeten Ausnahmen zu verabschieden.

Whitespace Search&Replace

Die Anforderung, mehrere Leerzeichen zusammenzufassen, taucht immer wieder auf. Bei Suchen/Ersetzungen mit Leerräumen bzw. Whitespace ist allerdings besondere Vorsicht geboten.
Zwischen Leerräumen befinden sich oft Marker, die bei der Suche ignoriert werde. Diese werden dann bei der Ersetzung unbeabsichtigt gelöscht. Das Grundsätzliche Problem habe ich bereits in diesem Post zusammengefasst.

Bei der Suche mit GREP gibt es die Möglichkeit mit \s alle Leerräume inklusive der Umbruchzeichen zu finden. Ab InDesign CS4 empfiehlt es sich mit der Unicode-Zeichenklasse \p{Z*} nur noch die Leerräume zu suchen.

Wenn ausschließlich nach Leeräumen gesucht wird, werden die folgenden Zeichen gefunden (whitespace.indd):

Wenn jetzt mehrere dieser Zeichen hintereinander auftreten, und durch einen einzigen Leerraum ersetzt werden sollen. Entstehen meiner Ansicht nach zwei grundsätzliche Probleme:

  1. Ignorierte Zeichen wie z.B. Indexmarken oder XML-Tags, die innerhalb des Suchergebnisses stehen, werden ungefragt verworfen.
  2. Die verschiedenen Leerräume haben eine unterschiedliche Wertigkeit. Wenn z.B. ein geschütztes Leerzeichen im Suchtreffer enthalten ist, sollte dieses bei der Ersetzung nicht durch ein einfaches Leerzeichen ausgetauscht werden.

Der erste Punkt ist unstrittig, hier muss um einen InDesign-Bug herumprogrammiert werden. Der zweite Punkt wird vermutlich je nach Ansicht des Anwenders bzw. Produkts unterschiedlich beantwortet werden. Deswegen muss man eventuell die Priorität der Zeichen, die erhalten bleiben sollen, individuell anpassen.

Wenn mit der Zeichenklasse \s arbeitet muss man sich zusätzlich noch überlegen, was bei der Zusammenführung mit den Formatierungseinstellungen der Absätze geschehen soll.
InDesign überträgt bei der Ersetzung die Einstellungen des vorletzten Absatzes auf den letzten Absatz. Ich bevorzuge aber das gegensätzliche Verhalten: Die Formateinstellungen des letzten Absatzes sollen erhalten bleiben. Mir reicht es zunächst, wenn das Absatzformat gerettet wird. Einzelne Einstellungen können aber nach dem gleichen Muster übernommen werden.

Um diese Probleme in den Griff zu kriegen habe ich ein Skript entwickelt. Es basiert auf dem findAndDo-Skript. Das gesamte Skript whitespacer.jsx steht zum Download bereit. Die interessantesten Teile stelle ich im folgenden vor:

Mit GREP werden alle Textstellen mit mindestens zwei aufeinanderfolgenden Leerzeichen gesucht:

app.findGrepPreferences.findWhat = "\\s{2,}";

Das Dokument muss rückwärts durchsucht werden, da Textänderungen den Index verschieben.

var _results = app.activeDocument.findGrep (true);   

Innerhalb einer for-Schleife werden die Suchergebnisse analysiert. Dazu wird mit indexOf geprüft, ob das Zeichen im Ergebnis vorhanden ist. Je weiter unten das Zeichen in Liste steht, desto höher ist die Priorität :

 // Normal Space
 if (_results[i].contents.indexOf ("\u0020") > -1) 
 _mostImportant = _results[i].contents.indexOf ("\u0020"); 
 // Nonbreaking Space
 if (_results[i].contents.indexOf ("\u00A0") > -1) 
 _mostImportant = _results[i].contents.indexOf ("\u00A0");
 // ..

Falls mehrere Absätze konsolidiert werden, merke ich mir das Absatzformat des letzten Absatzes. Hier müssen wiederum zwei Fälle unterschieden werden: Wenn der letzte Absatz mit Leerraum beginnt, gehört er zum Suchergebnis. Wenn nicht muss mit nextItem der nächste Absatz adressiert werden.

 var  _savedPStyle  = false;
 var _REbreak = RegExp("\\r","g");
 var _REStartsWhite = RegExp("^\\s");
 var _res = _results[i].contents.match (_REbreak);
 if (_res != null && _res.length > 1) {
   _lastPar = _results[i].paragraphs[-1];        
   if (_REwhite.test (_lastPar.contents) )
   _savedPStyle =_lastPar.appliedParagraphStyle;
   else 
   _savedPStyle =_results[i].paragraphs.nextItem (_lastPar ).appliedParagraphStyle; 
 }

Bei der eigentlichen Ersetzung werden alle Zeichen entfernt. Das zu erhaltende Zeichen, Marken, und bei der Suche ignorierte Zeichen werden geschützt:

 var _resArr = _results[i].characters.everyItem().getElements();
 for (var k = _resArr.length -1; k >= 0; k--) {
   var _char  = _resArr[k];
   if ( _char.contents != "\uFEFF" &&
        _char.contents  != SpecialCharacters.END_NESTED_STYLE &&
        _char.contents  != SpecialCharacters.INDENT_HERE_TAB &&
        _char.contents  != SpecialCharacters.DISCRETIONARY_HYPHEN &&
        _char.contents  != SpecialCharacters.DISCRETIONARY_LINE_BREAK &&
        _char.contents  != SpecialCharacters.ZERO_WIDTH_NONJOINER &&
        _char.contents  != SpecialCharacters.ZERO_WIDTH_JOINER &&
        k != _mostImportant)  _char.remove ();
   }
 }

Zu guter letzt wird das ehemalige Absatzformat erneut zugewiesen

 if (_savedPStyle) 
 _char.parentStory.characters[(_char.paragraphs[0].characters[-1].index + 1)].
paragraphs[0].appliedParagraphStyle;       
}

Das Skript ist noch nicht der Weisheit letzter Schluss. Insbesondere über die Performance müsste man noch nachdenken. Soweit ich das testen konnte läuft es sehr stabil.

Stolpersteine beim Suchen/Ersetzen

Bei der Arbeit mit GREP sucht man gerne nach Textbereichen bzw. nach zusammenhängenden Bereichen einer Zeichenklasse. Die Aufgabe, innerhalb eines Dokuments mit XML-Tags die Leerräume zu konsolidieren, errinerte mich wieder daran, dass ich schon länger dem Suchverhalten von InDesign auf den Grund gehen wollte.

Das grundlegende Problem ist, dass bestimmte Zeichen bei der Suche – egal ob GREP oder normal –  ignoriert werden (müssen), damit erwartbare Ergebnisse erzielt werden. Zu diesen Zeichen zählen neben den XML-Tags insbesondere auch die Index-Einträge, Textanker und Notizen, sowie einige andere Spezialzeichen.

Im Screenshot erkennt man die Darstellung der verborgenen Zeichen in InDesign. Die Unicode-Codepoints entsprechen der Repräsentation der Zeichen in InDesign und entsprechen nicht den Zeichen die laut Standard an diesen Positionen stehen.
In der Datei ignoredChars.indd ist diese und die folgende Tabelle enthalten.

Ein Problem ensteht erst bei der Ersetzung, da diese Zeichen dann entfernt werden. Konkret: Wenn diese Zeichen innerhalb eines Suchtreffers enthalten sind, werden sie bei der Ersetzung entfernt. Wenn man nicht aufpasst, kann man also munter Index-Einträge, Textanker, XML-Tags u.s.w. ohne Rückmeldung aus dem Dokument löschen.
Nur Notizen und Marken für ausgeblendete Bedingte Texte werden bei der Ersetzung korrekt behandelt: Eine Notiz innerhalb eines Suchtreffers wird bei der Ersetzung vor den Ersetzungsbegriff verschoben. Dieses Verhalten wünscht man sich eigentlich auch für alle anderen Spezialzeichen, zumindest aber für Index-Einträge und XML-Tags. Das Problem zieht sich durch alle Versionen einschließlich CS5.

Neben diesen Zeichen gibt es natürlich noch einen großen Problembereich bei der Suche nach Ligaturen und zusammengesetzeten oder diakritischen Zeichen. Wer diese einsetzt, sollte sich darüber bewusst sein, dass ein echte Ligatut fl (U+FB02) anders als die automatisch von InDesign zusammengesetzte Version aus f + l, nicht mehr mit der Suche nach „fl“ gefunden wird.

Was tun?

Zunächst ist es vermutlich wichtig sich über die Problematik bewusst zu werden. Ganz so klar wie bei den Notizen ist der Umgang mit gefundenen Spezialzeichen leider nicht. Soll z.B. ein Indexeintrag innerhalb eines Wortes, das durch ein ganz anderes ersetzt wird, erhalten bleiben – oder ist das Verhalten von InDesign sogar gewünscht?
Bei Indexeinträgen wäre z.B. ein Skript denkbar, das alle Indexmarken vor die Wörter stellt, so dass diese bei den folgenden Suchen nicht mehr zum Suchtreffer gehören. Alternativ könnte man die Ersetzung selber programmieren, was allerdings die Performance stark verlangsamen dürfte.

Die Aufgabe, den Leerraum zu konsolidieren, geht meines Erachtens sogar über das Problem mit den gelöschten Zeichen hinaus. Wenn man mit dem Regulären Ausdruck \s+ beliebig viel Leerraum durch einen einzelnen Leerraum ersetzen möchte, muss man bei der Ersetzung noch berücksichtigen, welcher Leerraum den höchsten Wert hat. Sollte z.B. ein geschütztes Leerzeichen gefunden werden, müsste dieses bei der Ersetzung erhalten bleiben. Noch höherwertiger wäre z.B. eine Zeilenschaltung.
Sobald mein Skript zur Konsolidierung von Whitepsace unter Berücksichtigung von ignorierten Zeichen fertig ist, werde ich es hier vorstellen.

Spezialzeichen die nicht ignoriert werden

Zum Abschluss noch die Tabelle mit Spezialzeichen, die bei der Suche nicht ignoriert werden. Eine verankertes Objekt innerhalb eines Wortes führt also z.B. dazu, dass das Wort nicht mehr über die Suche gefunden wird.
Bis auf Tabellen können alle Spezialzeichen explizit über GREP-Platzhalter gesucht werden.

Bild auf Blitzer prüfen

Es gab leider schon länger keinen Post mehr weil ich gerade intensiv an einem Buchprojekt zum Thema InDesign Automation arbeite. Infos dazu gibt es dann natürlich auch hier. Ein kleines aber feines Skript möchte ich doch kurz vorstellen.

Seit InDesign CS4 gibt ist ein automatisches Preflight (Aufruf über Fenster -> Ausgabe -> Preflight oder in der Statuszeile). Man kann allerlei nützliche Dinge während der Bearbeitung von  Dokumenten live prüfen lassen. Ich nutze gerne die Prüfungen auf Auflösung und Farbraum. Eine Prüfung nach Blitzern, also einem Versatz zwischen Bildrahmen und eigentlichen Bild, gibt es leider nicht.

Per Skript ist es ein leichtes – leider nicht Live und auch nur für rechteckige Rahmen. Letztere Einschränkung sollte in den meisten Fällen kein Problem sein.

Das Skript geht im in einer for-Schleife durch alle Bilder des Dokuments:

var _alleBilder = _dok.allGraphics;
for (var i = 0; i < _alleBilder.length; i++) {
 var _bild = _alleBilder[i];
 var _bildRahmen = _bild.parent;
  // Prüfung ...
}

Jedes Bild muss dann an allen vier Kanten auf Versatz geprüft werden. Exemplarisch für die Oberkante sieht das so aus:

if (_bild.geometricBounds[0] > _bildRahmen.geometricBounds[0]) {
  _fehlerMeldung= "Vertikaler Versatz oben\n";
  _fehler = true;
}

Wenn die y-Koordinate (geometricBounds[0]) vom eigentlichen Bild größer als die des Bildrahmens ist, gibt es einen Blitzer.

Das Skript vollständige Skript sollte ab CS3 unter allen InDesign Verisonen laufen. Hier kann es heruntergeladen werden: BilderaufBlitzerPruefen

Schneller live

Der CS5 Hype scheint mir schon vorüber zu sein, trotzdem noch der versprochene Post zur neuen Version.

Im Bereich Werksatz und XML gibt es auf den zweiten Blick  immer noch nicht viel neues. Beim genaueren Betrachten ärgert man sich allerdings, das viele Funktionen überhaupt nicht angefasst wurden. Fußnoten und  Kolumnentitel hätten sich über ein paar neue Features und lange bekannte BugFixes gefreut.

Neu und praktisch ist die automatische Erstellung von Bildunterschriften aus XMP-Metadaten. Im Zusammenspiel mit der ebenfalls neuen MiniBridge und einer gut gepflegten Bild-Datenbank ergeben sich hier gute Möglichkeiten zur Automation.

Leider fehlt eine automatische Nummerierung, die Möglichkeiten der Absatzformatvorlage helfen da auch nicht weiter, weil jede Bildunterschrift in einer neuen Story steht. Schön wäre die Möglichkeit gewesen für die Bildunterschrift neben Ebene und Absatzformatvorlage auch den Objektstil vorzugeben.

Außerdem wurde der XHTML-Export optimiert, der Seitenfluss orientiert sich jetzt an der Strukturpalette. Dies funktioniert auch beim EPub-Export, der ja auch auf dem XHTML-Export basiert, und kann da sehr nützlich sein.

Gut finde ich die Möglichkeiten von Hintergrundaufgaben z.B. beim PDF-Export der sich jetzt deutlich angenehmer anfühlt.

Richtig spannend finde ich das CS Review (File -> Create New Review… oder Live Menu). Mit einer Adobe ID kann man über Acrobat.com Dokumente oder einzelne Seiten anderen Benutzern zeigen. Diese können dort kommentiert, korrigiert und freigegeben werden.

Der Ablauf ist ziemlich einfach: Einloggen, über das Flyout Menu ein neues Review erstellen, dieses kann dann über acrobat.com betrachtet und mit anderen Benutzern geteilt werden:

Die Dokumente werden automatisch synchronisiert und alle Kommentare können dann im InDesign Layout angezeigt werden:

Gäbe es jetzt noch die Möglichkeit Textkorrekturen direkt zu übernehmen wäre das Feature perfekt. Insgesamt aber eine gelungene Online Integration der Software und im Gegensatz zu dem Spielzeug Kuler auch sehr produktiv nutzbar.

Mit dieser Möglichkeit können die Auftraggeber dann auch beweisen ob die Termine wirklich alle so eng sind.

Die interaktiven Features habe ich nicht weiter untersucht. Neben all den Problemen die sich aus dem Medienbruch ergeben stellt sich zusätzlich noch die Frage nach der Zukunft von Flash im Web.

Bildquellen automatisch auswerten

Das Erstellen von Bildquellenverzeichnissen ist meist ein ungeliebter Teil im Produktionsprozess. Um diesen zu automatisieren habe ich ein kleines Skript geschrieben welches einem die Arbeit abnimmt.

Natürlich kann auch dieses Skript nicht erraten welches Bild von welchem Urheber kommt, dazu greife ich auf die XMP-Metadaten zurück. Dies müssen vorher natürlich in Photoshop, Bridge oder einem ähnlichen Porgramm korrekt eingetragen worden sein.

Der eigentliche Trick besteht darin die XMP-Daten des Link Objekts auszulesen:

_bildQuellen.push([_dok.links[i].linkXmp.author, getPageByObject(_dok.links[i])] ) 

Alle Autoren werden zusammen mit der Seitenzahl  im Array _bildQuellen gesammelt. Dieser Array muss dann mit der eigenen Sortierfunktion sortCreator() am Ende noch nach alfabetisch nach den Rechteinhaber sortiert werden.

Eine interessante Erweiterung ist es, die Bildpositionen auf den einzelnen Seiten zu erfassen. Dazu müsste man den Aufbau allerdings etwas abändern und seitenweise durch das Dokument gehen.

Hier kann man das ganze Skript und eine Beispieldatei mit Wikipedia Bildern herunterladen.

JavaScript lernen

Ich mache an der Hochschule der Medien seit dem letzten Semester die Veranstaltung Technologisches Praktikum InDesign Satzautomation. Wesentlich Inhalte sind – wie könnte es anders sein – JavaScript für InDesign und Konzepte für den automatisieten Satz.

Die Unterlagen und Aufgaben liegen schon eine ganze Weile unbemerkt hier auf dem Server. Die Folien und Übungsaufgaben haben als Fokus Javascript mit InDesign und unterscheiden sich deswegen deutlich von den meisten mir bekannten webzentrierten JavaScript Einführungen.

2010-02-06_1653301. Termin

2. Termin

3. Termin

4. Termin

Leider fehlt der begleitende Text aus der Vorlesung. Aber für Leute die schon etwas programmieren können sicherlich eine hilfreiche Fundgrube.

Für Hinweise und Kommentare bin ich natürlich dankbar!

Viel Spaß beim Lernen!

E-Books jetzt ganz automatisch…

Schön wärs! Für sehr einfache und lineare Titel ist das denkbar. Sobald Informationen durch das Layout gegliedert werden scheitert jede Lösung, die versucht seitenbasierte Druckdaten automatsiert in ein strukturiertes Format zu überführen. Ohne eine akzeptable Implementierung künstlicher Intelligenz oder sorgfältige Vorbereitung der Daten kann das auch gar nicht anders sein.

Aus kaufmännischer Sicht ist der Wunsch kostenneutral E-Books zu generieren nachvollziehbar. Auf technischer Seite zeigt sich schnell wer sich ernsthaft mit dem Thema beschäftigt hat.

In diesem Beitrag geht es natürlich um den EPub-Export von InDesign. Der Export über Datei -> Export for Digital Editions ist erstaunlich gut. Wer ein paar Punkte beachtet kann bei einfachen Titeln zu sehr guten Ergebnissen kommen.

2009-12-28_190032

Zunächst ist wichtig, das alle Seitenelemente die nicht ins E-Book übernommen werden sollen auf Musterseiten angelegt werden – ein per Hand erstellter Kolumnentitel oder eine versehentlich gelöste Seitenzahl wird höchstwahrscheinlich an einer völlig falschen Stelle im Ebook auftauchen.

Beim Textaufbau ist auf die richtige Textverkettung der Rahmen zu achten – Textabschnitte werden immer vollständig exportiert.

Die größten Probleme in klassischen InDesign-Datein dürften jedoch per Hand platzierte Bilder verursachen. Diese werden ganz am Ende, bzw. erst nach dem Textabschnitt zu dem sie zugeordnet sind platziert. Abhilfe schafft die Verankerung der Bilder an den entsprechenden Stellen im Text. Dies dürfte in klassischen Workflows fast immer zu Nacharbeiten führen.

Ein weiteres Problem sind Bilder mit Legenden, diese müssen zunächst gruppiert werden, damit sie beim Export zusammengehalten werden.

Das Einbetten von Schriften ist gleich dopplet Problematisch: InDesign bettet nur Schriften mit entsprechender Erlaubnis ein. Dazu ergibt sich ein rechtlicher Problem bei der Weitergabe von Schriften in epub-Daten, da diese lediglich kopiert durch einfaches entpacken extrahiert werden können. Mit der Verwendung von freien Schriften kann man sich entsprechenden Ärger ersparen.

Selbstverständlich können keine strukturellen oder semantischen Informationen – wobei die Frage offen bleibt inwieweit die semantischen Auszeichnung von Informationen in naher Zukunft an realer Bedeutung gewinnt – exportiert werden.

Wer dann alles richtig gemacht hat wird trotzdem in den meisten Fällen das erstellt EPub öffnen und einzelne Teile nacharbeiten. Es bietet sich an ein eigenes CSS für alle Publikationen festzulegen, in diesem können dann auch ganz elegant freie Schriftarten zugewiesen werden. Zur Nacharbeit bieten sich die Technologien Java, XSLT udn CSS an. Bei einem höheren Datenvolumen sollten diese Schritte natürlich automatisiert werden.

Zusammenfassend würde ich sagen das ein EPub-Export gelingen kann. Jedoch sollte man sich vom automatischen Traum schnell verabschieden:

  1. Es werden detaillierte Bearbeitungskonventionen für die Arbeit in InDesign benötigt.
  2. Ein »EBook-Preflight« per Skript oder Abhakliste sollte entwickelt werden.
  3. Eine Nachbearbeitung des EBooks im Bereich Metadaten, Titelei


XML und InDesign – es könnte so einfach sein!

Aus einer langen Pause starte ich mit einem doppeldeutigen Titel, natürlich könnte ich auch mal einfach ein wenig mehr bloggen, aber Adobe hätte mit dem gleich vorgestellten Skript vielen Menschen viel Frust ersparen können. Aber der Reihe nach:

Der erste Versuch XML-Dokumente innerhalb von InDesign zu verwenden scheitert meist kläglich. Das Problem ist das kuriose Whitespace Handling. Die meisten XML-Dokumente enthalten Whitespace zwischen nicht texttragenden Elementen um sie leichter lesbar zu machen (Pretty Print) oder weil ein vorheriger Bearbeitungsschritt diesen erzeugt hat.

<root>
-> Whitespace  <abs>text</abs>
</root>

Jeder der schon einmal den Quelltext einer Website betrachtet hat kennt das Phänomen.

InDesign importiert nun den Whitespace zwischen den Elementen und stellt ihn vollständig dar (ähnlich dem XML-Attribut xml:space=“preserve“ oder dem  <pre>-Tag von HTML). Unbrauchbare Dokumente und frustrierte Anwender sind die Folge.

Mit der Version CS3 dachten auch viele Adobe hätte das Problem in den Griff bekommen, denn beim XML-Import tauchte eine Option zum Whitespace Handling auf.

xmlImportOptions

Leider ist diese Funktion praktisch nutzlos, denn entweder bekommt man einen langen Text ganz ohne Zeilenumbrüche oder eben das ehemalige Verhalten bei dem alle Whitespace Elemente umgesetzt wurden.

Zur Lösung des Problems musste man entweder ein XSLT zum Preprocessing verwenden oder aber XML-Rules selber skripten. Für Anfänger sind beide Technologien etwas komplex, insbesondere wenn man sich klar macht, das einfach nur strukturierte Daten importiert werden sollen. Auch in CS4 hat sich dahingehend leider nichts verändert.

In jeder InDesign-XML-Schulung sprach ich bis heute immer davon, das bei der Funktion Map Tags to Styles… (Befehl Formate zu Tags zuordnen… aus dem Kontextmenu der Strukturansicht) ein Häkchen fehlen würde, welches das entsprechende Element als Absatz (Blocklevel-Element) auszeichnet. Diese Option würde steuern welche Elemente ganze Absätz beinhalten und entsprechend einen Zeilenumbruch hinzufügen.

Vor ein paar Tagen kam mir dann eine noch einfachere Idee: Einfach ein Skript schreiben welches allen Elementen, denen in der Zuordnungstabelle ein Absatzformat zugewiesen ist, beim Importprozess einen Zeilenumbruch mitgibt. Denn die Zuweisung eines Absatzformats kennzeichnet ja eben das Element als Blocklevel-Element.

Das geht dann auch erstaunlich einfach: Das importieren der XML-Daten kann von InDesign übernommen werden. Der Trick ist eine For-Schleife über die ImportMap (Zuordnungstabelle) mit Prüfung ob ein Absatzformat zugewiesen ist. Vorraussetzung ist natürlich, dass die Zuordnung von Absatzformaten zu Tags bereits vor dem Import vorgenommen wurde, ohne je ein Skript editieren zu müssen.

for (i = 0; i < _dokument.xmlImportMaps.length; i++) {
  if (_dokument.xmlImportMaps[i].mappedStyle.constructor.name == "ParagraphStyle" )
  { ... }
}

Jetzt muss nur noch eine XML-Rule für jedes so ermittelte Element programmiert werden:

_xpath = "//" + _dokument.xmlImportMaps[i].markupTag.name;
...
var _proc  = app.xmlRuleProcessors.add([_xpath]);
var _match = _proc.startProcessingRuleSet(_dokument.xmlElements[0]);
while( _match!=undefined ) {
  _node = _match.element;
  _node.insertTextAsContent ("\r", XMLElementPosition.afterElement)
  _match = _proc.findNextMatch();
}

Mit Hilfe dieses Skripts kann jetzt jeder ohne XSLT oder Programmierkenntnisse XML in InDesign verarbeiten. Einfach das Skript herunterladen und  in das Bedienfeld Skripte einfügen. Zum Testen habe ich eine XML-Instanz und ein InDesing Dokument vorbereitet: Download XML Test ZIP.

Viel Spaß!