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ß!

Bild und Legende

Ü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.

einfache_story

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.

Abstand vor

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.

abstandvor

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.

Zeichenformate filtern

Meine persönliche Lieblingsfunktion von CS4 ist die Möglichkeit mit so gennanten GREP-Styles bestimmten Textbereichen Zeichenformate zuzuweisen. Sicherlich nicht die wichtigste Neuerung aber als großer Fan von Regulären Ausdrücken ist dieses Feature Pflicht.

Die Funktion ist im Absatzformatvorlagen-Dialog unterhalb der Verschachtelten Formate zu finden. Die Anwedung ist durchaus intuitiv. Man muss allerdings Reguläre Ausdrücke beherrschen bzw. sich mit der angebotenen Übersicht arrangieren.

Im unteren Beispiel werden alle Preise ausgezeichnet die aus Ziffern bestehen und denen die Buchstabenkombination EUR folgt. Z.B. Dieser Blogeintrag könnte 15 EUR kosten.

Im Detail sieht das so aus:

  • \d+ bedeutet mindestens beliebig viele Ziffern jedoch mindestens eine (1…n)
  • mit (?=Ausdruck) wird sichergestellt, das nach den gefundenen Ziffern der Ausdruck stehen muss
  • der Ausdruck \s?EUR erlaubt ein optionales Leerzeichen gefolgt von der Zeichenkette EUR.

Nun werden alle Ziffernfolgen mit dem entsprechenden Zeichenformat formatiert. Ein kleiner Fehler ist allerdings noch zu beheben: Damit auch durch Komma abgetrennte Preise erkannt werden muss der Ausdruck wie folgt erweitert werden:

[\d,]+(?=\s?EUR)

innerhalb der eckigen Klammern wird definiert welche Zeichen auftreten dürfen, im Beispiel Ziffern und das Komma.

Leider kann über das Skripting Interface nicht auf die Instanzen zugreifen auf die das Styling angewendet wurde.
Dazu muss man selber die entsprechenden Absätze mit dem Regulärem Ausdruck durchsuchen. Wenn man dies generisch lösen will, kann das insbesondere bei den schon seit CS3 vorhandenen verschachtelten Formaten aufwändiger werden.

Die Idee alle Textbereiche über

TextStyleRange.appliedNestedStyles

auszuwerten funktioniert nur so lange, bis zusätzliche Veränderungen innerhalb von vorformatierten Bereichen diese weiter aufteilen.

IDML

Mit IDML gibt es seit CS4 eine von Adobe vorgesehene Repräsentation von InDesign-Dokumenten in XML. Viele fragen mich, was das eigentlich bedeutet bzw. ob IDML für ihren Workflow relevant ist.

Zunächst einmal: Das Schnittstellenformat richtet sich an Solution-Provider und wird für den durchschnittlichen Anwender eher unbedeutend bleiben. Die eigentlichen Neuigkeiten sind, dass Adobe IDML im Gegensatz zu INX offiziell unterstützt, die Spezifikation veröffentlicht wurde und dass das Dateiformat deutlich übersichtlicher geworden ist.
Ganz grundsätzlich bleibt natürlich das Problem, dass ein extern generiertes IDML die Ergebnisse der InDesign-Satz-Engine praktisch nicht vorhersehen kann. Somit sind keine interaktiven Bedingungen und Gestaltungsregeln umsetzbar, die sich erst nach dem endgültigen Satz  auswerten lassen. Im Endeffekt erreicht man damit dann einen typischen XSL-FO Automatisierungsgrad. Für Kataloge und datenbankorientierte Produkte wahrscheinlich ein kleineres Problem.

IDML wird wahrscheinlich für die folgende, natürlich nicht vollständige, Sammlung von Aufgaben verwendet werden:

  • Dokumente außerhalb von InDesign erstellen und verarbeiten z.B. aus Datenbanken oder XML-Dateien.
  • Gut vorstellbar ist auch, dass Übersetzungstools auf der Basis von IDML arbeiten (so wie es jetzt schon Tools auf der Basis von INX gibt).
  • Vollautomatische Inhaltsanpassungen in Musterdokumenten, z.B. in Web-Applikationen.
  • Zusammenstellen von Dokumenten aus verschieden Teilkomponenten.
  • Einsatz innerhalb von XSLT-Workflows.

Um das zu erreichen hat sich Adobe einige Ziele für IDML gesetzt:

  • Vollständigkeit Alle Objekte, Attribute und Voreinstellungen sollen durch IDML repräsentiert werden können.
  • Lesbarkeit Gutes XML-Grammatiken sind auch von Entwicklern lesbar und verständlich, XML-Standard-Tools sollten sowieso keine Probleme haben.
  • Robustheit Sollte eine Selbstverständlichkeit sein.
  • Kompatibilität IDML soll ähnlich wie INX zur jeweils vorigen Version kompatibel sein.
  • Performance Die InDesign Standalone Applikation zu schlagen ist nicht so schwer :-)

Ganz interessant ist auch der Ansatz von Adobe, dass Skripting Objektmodell als Grundlage von IDML zu verwenden. Dies bedeutet, dass mit einem skriptbaren Plugin IDML mit den hinzugekommen Fähigkeiten erweitert werden kann. Dazu ist ein Schema-Generator vorgesehen, der für die jeweils aktuelle Konfiguration von InDesign ein Schema generiert. Mit dem so erstellten Relax-NG Schema kann man dann seine XML-Instanzen validieren.

Zur IDML Familie gehören noch die folgenden Formate, die letztlich auf der gleichen Grammatik beruhen:

  • IDMS (InDesign Markup Snippet) Zur Wiederverwendung von in InDesign gestalteten Objekten
  • ICML (InCopy Markup Language) Inhalte in InCopy bearbeiten
  • ICMA (InDesign Markup Assignment) Hier können Inhalte einem Autor zur Bearbeitung in InCopy zugewiesen werden.

Spätestens seit Microsofts Open XML Standard wissen wir allerdings, dass ungeprüfte Ankündigungen solcher Art nicht das Papier Wert sind auf dem sie stehen. Ich habe mich bis jetzt nur kurz mit IDML beschäftigen können. Erste Tests sind aber vielversprechend, wobei mir dabei natürlich zugutekommt, dass ich das Skripting Objektmodell schon kenne.

Um eine Vorstellung vom Format zu bekommen lohnt ein Blick in eine IDML-Datei. Ganz ähnlich wie andere datenzentrierte XML-Formate ist die Datei ein ZIP-Container, der verschiedene, untereinander verlinkte, XML-Dateien enthält. Die wichtigsten Inhalte sind:

  • Eine Übersichtsdatei designmap.xml
  • Die Typdefinition mimetype
  • Encoding und Dateiaufbau im Ordner META-INF
  • Eine Datei pro Musterseite im Ordner MasterSpreads
  • Formatangaben, Schriften, Farben, Voreinstellungen im Ordner Resources
  • Die Inhaltsseiten und deren Objekte im Ordner Spreads
  • Der Eigentliche Inhalt im Ordner Content
  • Die XML-Tags des InDesign Dokuments befinden sich im Ordner XML

Die XML-Grammatik orientiert sich am Objektmodell. Als Beispiel dazu

<ParagraphStyleRange AppliedParagraphStyle="ParagraphStyle/Absatzformat">
   <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/$ID/[No character style]">
     <Content>Hallo Welt ich bin </Content>
   </CharacterStyleRange>
   <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/fett">
     <Content>fett</Content>
   </CharacterStyleRange>
</ParagraphStyleRange>

Im Prinzip recht ähnlich zu den Eigenschaften der Klasse TextStyleRange im Skripting.

Mehr Information findet in der InDesign developer documentation von Adobe. Hier ist das Kochbuch empfehlenswert. Sobald ich eigene Erfahrungen mit IDML gesammelt habe natürlich auch hier.