Automate InDesign with JavaScript

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.

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.

Über mangelnde XML-Funktionen von InDesign wurde schon viel geschrieben. Praktisch ist das nachträgliche Erstellen von XML-Strukturen in einem klassisch aufgebauten InDesign-Dokument nur mit einfachsten Strukturen und Dokumenten möglich.

Über die Funktion Formate zu Tags zuweisen und die Tagging Voreinstellungen aus dem Kontext-Menu der Strukturpalette lassen sich Block-Level- und Inline-Elemente verknüpfen, Bilder und Tabellen werden zumindest ausgezeichnet.

Mit InDesign Bordmitteln lässt sich maximal das Folgende XML-Ergebnis erzielen:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Root>  <textrahmen> <u1>Überschrift 
</u1>  <p>Lorem ipsum <bold>dolor sit amet</bold>, consetetur ....</p>  </textrahmen> <textrahmen>  <legende><Figure href="file:///C:/Dokumente%20und%20Einstellungen/hp/Desktop/bild.png"/>
 Diese Bild zeigt das Logo des InDesign-Blogs </legende> </textrahmen>  <textrahmen>  <p>2tes Lorem ipsum dolor sit amet, consetetur ...</p>  </textrahmen> </Root>

Das aber auch nur, wenn das Bild als verankertes Objekt im Textrahmen der Legende platziert ist. In den meisten Fällen wird so allerdings nicht gearbeitet und Legende und Bild haben keinerlei Verknüpfung mehr. Die Anordnung der textrahmen-Elemente (Es handelt sich eigentlich um Stories, also auch verknüpfte Textrahmen) innerhalb der Strukur entspricht dem Erstellungszeitraum und nicht dem optischen Eindruck, was die Ergebnisse der meisten Exporte noch weitaus verwirrender gestaltet als das obige Beispiel.

Für ein produktives Konvertieren von alten Daten bietet sich ein Skripting-Workaround an. Als Konvetion wird festgelegt, das Legende und Abbildungspaar immer gruppiert sein müssen.

Das Skript-Snippet ist sehr einfach, für eine bessere Übersichtlichkeit verzichte ich auf das Handling der Gruppen und verarbeite nur die erste:

var _group = app.activeDocument.groups[0];
if (_group.allGraphics.length == 1 && _group.textFrames.length == 1) {
  var _xmlAbb = app.activeDocument.xmlElements[0].xmlElements.add("abbildung");
  // Falls die Grafik bereits verknüpft ist entfernen ich den Tag
  if (_group.allGraphics[0].associatedXMLElement != null) _group.allGraphics[0].associatedXMLElement.untag();
  _xmlAbb.xmlElements.add("bild", _group.allGraphics[0]);
  // Falls der Textrahmen bereits verknüpft ist entfernen ich den Tag
  if (_group.textFrames[0].associatedXMLElement != null) _group.textFrames[0].associatedXMLElement.untag();
  _xmlAbb.xmlElements.add("legende", _group.textFrames[0]);
}

Jede Gruppe die genau eine Abbildung und einen Textrahmen enthält wird damit  in die folgende Struktur, die eher einer sinnvollen XML-Struktur genügt,  gebracht:

<abbildung>
   <bild href="...bild.png"></bild>
   <legende>Diese Bild zeigt das Logo des InDesign-Blogs </legende>
</abbildung>

Eine Lösung für die Anordnung der Elmente in der richtigen Reihenfolge steht noch aus. Genauso ist es natürlich denkbar per Skript nah beeinander stehende Bild/Legende Objekte zu suchen und nicht den Umweg über die Gruppierung zu gehen.

InDesign rendered das Absatzattribut Abstand vor nur zwischen Textzeilen allerdings nicht in der ersten Zeile eines Textrahmens. Für einen automatischen Umbruch ist allerdings ein Feature notwendig, das bspw. abgesenkte Kapitelüberschriften die unterhalb des Satzspiegels beginnen ermöglicht. Textrahmen manuell anzupassen verbietet sich aus verschiedenen Gründen. Beim Attribut Abstand nach gibt es das gleiche Problem, allerdings fehlt hier die praktische Relevanz.

Ein möglicher Workaround ist es, die Schriftart der Überschrift auf einen größeren Wert zu stellen und dann wieder kleiner zu skalieren. Die größere Schriftgröße muss dann natürlich dem gewünschten Abstandswert entpsrechen was bei Prozentangaben nicht ganz trivial ist.

Im Bild ist die obere Überschrift in 12pt die untere in 30,125pt mit einem Skalierungsfaktor von 40% dargestellt. Zur Erzeugung des Screenshots wurden zwei Textrahmen übereinandergelegt.

Dieses Verfahren funktioniert erstaunlich gut, bei einem manuell eingestellten Zeilenabstand auch für mehrzeilige Überschriften. Wer etwas Rechenfaul ist dem kommt mein spacebefore-Skript zu gute. Eigentlich ziemlich straight-forward heruntergeschrieben:

  var abstandVor = 5; //in Millimetern
  var par = app.selection[0].paragraphs[0];
  //1mm == 2.834645669pt
  abstandVor = abstandVor * 2.834645669;
  var origGroesse = par.pointSize;
  // Schriftgröße neu setzen
  par.pointSize = origGroesse + abstandVor;
  // Scale berechnen und zuweisen
  var scale =  (origGroesse / (origGroesse + abstandVor )) * 100;
  par.verticalScale = scale;
  par.horizontalScale = scale;

Leider entspricht das noch nicht ganz dem gewünschten Ergebnis, weil die Schrift anhand der Versalhöhe am Textrahmen ausgerichtet wird. Dazu muss der Schrift nochmal ungefähr die Hälfte der Größe hinzugegeben werden.

  abstandVor = (abstandVor + (abstandVor/2.5)) * 2.834645669;

Der Wert 2.5 ist allerdings nur ein ungefährer Mittelwert, ein genauer Wert ist Abhängig von der Versalhöhe der Schrift. Auf diesen Wert hat man über InDesign keinen direkten Zugriff. Er ließe sich zwar theoretisch berechnen, wenn die Schrift temporär in Pfade umgewandelt würde. Bzw. in der ersten Zelle über den Abstand zwischen Grundlinie und Rahmenoberkante. Das überlasse ich aber mal jemanden anderen und gebe mich mit einem etwas ungenauen Ergebnis zufrieden.