Beim EPUB- bzw. HTML-Export (Seit CS5.5 Datei → Export) stellt sich oft die Frage, welche Seitenobjekte und welche Formateinstellungen wie exportiert werden. Die folgende Tabelle gibt eine Übersicht über die Umsetzung in HTML-Elemente bzw. CSS-Regeln. Auffallend ist, dass der HTML und EPUB-Export manchmal zu verschiedenen Ergebnissen führen. Ich vermute, dass es noch weitere Unstimmigkeiten gibt – prinzipiell sollte meiner Ansicht das gleiche Ergebnis generiert werden. Einen entsprechenden Bug-Report habe ich bei Adobe eingereicht.
In den grau hinterlegten Zeilen finden Sie Seitenobjekte/Absätze bzw. Tabellen und deren xhtml-Umsetzung. InDesign schreibt übrigens xhtml mit ein paar HTML5 Einsprengseln – aber eigentlich kein HTML wie man anhand dem Namen der Funktion vermuten würde. In den weißen Zellen folgen dann immer die CSS-Eigenschaften für das vorhergehende Element.
Alternativ kann man sich auch die inhaltlich gleiche PDF Aufbereitung herunterladen und ausdrucken.
Ergänzungen und Korrekturen sind willkommen! Hinterlassen Sie einen Kommentar oder schicken Sie mir eine Mail!
| Objekt/ InDesign-Eigenschaft |
Element/ CSS-Deklarationen |
Anmerkung |
| Dokument | <body> |
Ggf. Sprachattributxml:lang="en-US" |
| Ränder | HTML: body { margin: 0.5em; }EPUB: @page { margin : 0.5em; } |
Einstellung im Export-Dialog |
| Gruppen | <div class="ObjectStyle"></div> |
Bei Gruppen ohne Objektformat class="group" |
| Rahmen von Bildern | <div class="ObjectStyle"></div> |
|
| Bilder | <img class="ObjectStyle" |
Format wie in Objektexportoptionen oder Export-Dialog JPG, GIF oder PNGBei Bildrahmen ohne Objektformat class="image" |
| Bildausrichtung und -abstände | display: block; |
Bei Objektexportoptionen Klasse img.media-# |
| Verankerte Bilder mit Konturenführung |
<img class="leftFloat".../> |
Feste CSS-Regel:.leftFloat {Links/Rechts Aufteilung: Position von der Zeilenmitte. |
| Textabschnitte/Textrahmen | <div class="ObjectStyle"></div> |
Objektformat des ersten Textrahmens, bei Textrahmen ohne Objektformat class="story" |
| Absätze | <p class="ParagraphStyle"></p>Lokale Abweichungen mitclass="para-style-override-#" |
Zuweisung von <p>, <h1>,…<h6>und/oder Klasse möglich. Ggf. Sprachattribut xml:lang="en-US" |
| Ausrichtung | text-align: left; |
|
| Einzug erste Zeile | text-indent: 1px; |
|
| Abstände | margin: 4px 5px 6px 7x; |
Kein Abstand: margin: 0; |
| Weitere Formatierungen bei den Inline-Formaten | ||
| Nummerierte Liste | <ol></ol> |
Statische Listen mitGgf. Sprachattribut xml:lang="en-US"<ol class="List-#"> |
| Aufzählungsliste | <ul> <li class="Absatzformat"></li> |
Ggf. Sprachattribut xml:lang="en-US"<ul class="List-#"> |
Abstand links <ol>/<ul> |
margin-left: 9px; |
|
Abstand oben <li> |
margin-top: 0; |
|
Abstand unten <li> |
margin-bottom: 10px; |
|
Abstand rechts <li> |
margin-right: 10px; |
|
| Weitere Formatierungen wie bei Absatz oder Inline-Formaten | ||
| Inline-Formatierung | <span class="CharacterStyle">Lokale Abweichungen mitclass="char-style-override-#" |
Zuweisung von <em>, <strong>, <span> und/oder Klasse möglich.Ggf. Sprachattribut xml:lang="en-US" |
| Schriftart | font-family: "Schriftname"; |
EPUB CSS: Schriftdeklaration über@font-face {...} |
| Schriftgröße | font-size: 0.83em; |
|
| Fett | font-weight: bold; |
|
| Kursiv | font-style: italic; |
|
| Kapitälchen | font-variant: small-caps; |
|
| Farbe | color:#000000; |
|
| Hoch/Tiefstellung | vertical-align: super; |
|
| Unterstrichen | text-decoration: underline; |
|
| Durchgestrichen | text-decoration: line-through; |
|
| Kapitälchen | font-variant: small-caps; |
|
| Versalien | text-transform: uppercase; |
|
| Harter Zeilenumbruch | <br/> |
|
| Hyperlinkziele/Textanker | <a id="Name des Ankers"/> |
|
| Hyperlink | <a href="#Name des Ankers"></a> |
|
| Tabellen | <table id="table-#" class="Tabellenformat"> |
Feste CSS-Regel:table.Tabellenformat { |
| Kopf-, Körper-, Fußbereich |
<thead></thead>, |
Feste CSS-Regel:tbody, thead, tfoot, tr, td, th { |
| Tabellenzeilen | <tr></tr> |
Bei angewählter Option Abwechselndes Muster Zeile <tr class="Row-Column-#"> |
| Flächenfarbe | background-color: #D90000; |
|
| Tabellenspalten | <col class="Row-Column-#" /> |
Erstellung nur bei angewählter Option abwechselndes Muster Spalte |
| Flächenfarbe | background-color: #D90000; |
|
| Tabellenzellen | <td>Lokale Abweichungen mitclass="cell-style-override-#" |
Feste CSS-Regel:td { |
| Flächenfarbe | background-color: #D90000; |
|
| Zellenversatz | padding-bottom : 9px;padding-left : 6px;padding-right : 9px;padding-top : 9px; |
Unklare/fehlerhafte Umsetzung |
| Video | <div class="image"> <video id="FileName.mp4" width="#" height="#" tabindex="0"> <source type="video/mp4" src="File.mp4"> </source> </video></div> |
|
| Audio | <div class="image"> |
|
Heute war das markupFORUM in Stuttgart. Es gab viele interessanten Beiträge von XSLT bis EPUB. Es hat richtig Spaß gemacht Fachpublikum zu treffen und über die Zukunft von XML zu diskutieren.
Meine Vortragsunterlagen zum Thema »InDesign und XML – wie geht’s weiter« können Sie hier herunterladen.
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.
Hier finden Sie die Unterlagen von meinem Vortrag „Strukturierte Daten vs. DTP Layoutsoftware“ auf der tekom Jahreskonferenz am 3. November 2010.
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 den Whitespace zwischen den Elementen und stellt in 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.
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 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 die Skripts-Palette einfügen. Zum Testen habe ich eine XML-Instanz und ein InDesing Dokument vorbereitet: Download XML Test ZIP.
Viel Spaß!
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.
Der Import von XML-Daten in InDesign richtet sich ja nach der etwas eigenwilligen Interpretation von XML durch Adobe. Wobei die grundlegende Problematik des Whitespace-Handling im XML-Standard zu wünschen übrig lässt und den Applikationsanbieter bezüglich des Renderings etwas im Regen stehen lässt. Hat man die Probleme beim Import umschifft – im wesentlichen muss beachtet werden, dass jeglicher Whitespace im InDesign Dokument umgesetzt wird – erlebt man beim Export die nächste Überraschung.
Die Betrifft im wesentlich zwei Bereiche:
- Der Unicode Codepoint des Zeilenwechsel wird in der Info-Palette von InDesign als 
 (Carriage Return) der Soft-Return als 
 (Line Feed) angezeigt. Im exportieren XML Dokument wird für den Zeilenwechsel der etwas unübliche Paragraph Separator 
 für einen Soft-Return der Line Separator 
 verwendet. Eigentlich ist die Idee gar nicht schlecht eindeutige und dafür vorgesehene Unicode Zeichen zu verwenden. Problematisch ist dabei jedoch, dass die Zeichen von fast keinem Programm interpretiert werden und somit in Text-/XML-Editoren bestenfalls als Kästchen dargestellt werden.
Außerdem sind es keine zugelassenen Whitespace Zeichen. Da in InDesign die Formatierung von Block-Level-Elementen sinnvollerweise über eben diese Zeichen geregelt wird, steht man vor dem Dilemma entweder nicht valide Daten zu bekommen oder die Zeilenwechsel in Text-Elementen unterzubringen – wo man sie allerdings auch nicht haben will.
Um valide Daten zu bekommen hilft ab CS3 die Option im Exportdialog die Zeilenwechsel als Leerzeichen auszugeben. - Der zweite Problembereich sind die Spezialzeichen von InDesign die teilweise gar nicht in Unicode abbildbar sind. Diese werden nämlich einfach verworfen oder bei entsprechende Export Option als Leerzeichen umgesetzt. Glücklicherweise betrifft das nur wenige Zeichen:
1. Den nach Rechts austreibenden Tabulator
2. Das Einzug Hier Zeichen
3. Das Endzeichen für geschachtelte Formate
4. Alle manuellen Spalten- und Seitenwechsel.
5. Automatisch generierte Seitenzahlen und Section Marker
In beiden Fällen hätten sich Processing-Instrucions angeboten, damit wäre eine exportierte XML-Datei identisch wieder reimportierbar geworden. Und ganz nebenbei wäre mit einem solchen Set von Processing Instrucitons der Import von XML-Daten übersichtlich und prozesssicher umsetzbar.
Für eine Übersicht über die verwendbaren Sonderzeichen innerhalb von InDesing habe ich ein kleines Skript entworfen welches den SpecialCharacters Enumerator auswertet. Enstanden ist ein Dokument mit allen InDesign-Sonderzeichen. Dieses habe ich dann als XML exportiert, mit einem kleinen XSLT um die Unicode Codepoints erweitert und dann reimportiert. Das Ergebnis kann man hier herunterladen.
