Anwenderdoku

h1. Richtlinien und Einschränkungen in der Arbeit mit InDesign

{{>toc}}

h2. Lesereihenfolge sicherstellen

h2. Einschränkungen

h3. Absatzlinien

können grundsätzlich aus den Formaten ausgelesen werden. Jedoch kann @transpect@ die Linien nicht 1:1 so wiedergeben, wie sie in InDesign definiert sind, da die Linien als @border@ mitgenommen werden und der Versatz als @padding@, sind hier viele Möglichkeiten nicht machbar.

Einschränkungen:

* Breite der Linien. Ist immer 100%, auch, wenn sie in InDesign kürzer eingestellt wurde

* negativer Versatz. Führt zu Fehlern. Darf nur positiv sein

* Absatzlinien als Hintergrundfarbe: Funktioniert nicht

* Absatzlinien, mit Versatz, der über den momentanen Absatz hinausgeht. (die Linie erscheint im ePUB immer über dem Absatz, an dem sie definiert wurde, mit dem entsprechenden Versatz als Abstand.)

→ machbar sind nur einfache, durchgängige Linien darunter und darüber, auch in unterschiedlichen Strichstärken und Farben.

h3. Ebenen

Grundsätzlich stellt die Arbeit mit mehreren Ebenen für den Konvertierungsprozess ein Problem dar, weil die Inhalte der einzelnen Ebenen dem Haupttextfluss nicht zugeordnet werden können.

Was jedoch funktioniert, ist, einzelne Textrahmen auf anderen Ebenen mithilfe des [[InDesign#StoryID-und-StoryRef|StoryID/StoryRef-Mechanismus]] im Haupttextfluss der Hauptinhaltsebene zu verankern.

h3. Farbig hinterlegte Absätze

Sowohl als Absatzlinie als auch mit den neuen Features von InDesign CC.

h3. In InDesign erstellte Grafiken

* Werden bei der Konvertierung zur Zeit ignoriert. Formen wie Linien und Pfade werden entfernt. 

* Auch Rahmen, die andere Formen als Rechtecke haben, werden nicht berücksichtigt. Deren Inhalte sollten mit dem Textfluss verkettet sein. Die Forminformation geht verloren.

* Auf Gestaltung mit leeren Rahmen als dekorative Elemente sollte unbedingt verzichtet werden. Stattdessen binden Sie bitte echte Grafiken ein. Zum Beispiel können Sie ein PDF aus einer solchen Grafik generieren, was Sie in InDesign einbinden können und mithilfe des [[Bildexportskriptes|Skripte#Bild-Export-Skript-image-exportjsx]] exportieren können.

h3. GREP-Stile

Wie viele verschachtelte Formate sind auch GREP-Stile bei der Konvertierung mit transpect nicht berücksichtigt. Zeichenformate, die über diese Option im Absatzformat zugewiesen werden, werden zur Zeit nicht berücksichtigt.

h3. Grundlininenversatz

Die Eigenschaft ist im EPUB nicht anwendbar, sie wird zur Zeit nicht transportiert.

h3. Leerzeilen und Tabulatoren

Sind grundsätzlich nicht als Layoutwerkzeuge für Titel, die über @transpect@ produziert werden benutzbar.

h4. Leerzeilen

Um Abstände zwischen Absätzen auch für das ePUB zu realisieren, sollten entsprechende Tilden-Formate verwendet werden (z.B. »GT~LZ_vor«). 

Bei C.H.Beck sind auch manuelle Abstände erlaubt, bei Campus und Beltz landen diese nicht als Abstand im ePUB und werden im Fehlerreport angemerkt.

h4. Tabulatoren

Tabulatoren können im ePUB und XML nicht sinnvoll repräsentiert werden. 

In einigen Formaten wird ein einzelner Tabulator berücksichtigt, eine Auswahl:

* in Überschriften können sie zwischen Ziffern und der eigentlichen Überschrift benutzt werden

* im Glossar

* in Zeittafeln

* Listen

Aus diesen Formaten wird dann links und rechts vom Tabulator jeweils ein eigenes Element generiert.

Folgen *mehrere Tabulatoren* aufeinander oder befinden sich mehrere in derselben Zeile um Inhalte zu strukturieren, sollte auf Tabellen ohne Linien zurückgegriffen werden.

Aus rechtsbündigen Tabulatoren (z.B. der Autorenname in der Einleitung) wird für die Repräsentation im ePUB eine Tabelle aus dem Absatz erstellt. Deren rechter Zelleninhalt wird dann rechts ausgerichtet.

h3. Schriftkodierung

Um Zeichen im XML und ePUB wie in InDesign darstellen zu können, müssen Fonts verwendet werden, die UTF-8 kodiert sind. Das heißt, dass die Schriftzeichen an definierten Stellen liegen müssen, wo sie auch bei anderen UtF-8-kodierten Schriften liegen.

Im Normalfall ist das bei gut ausgebauten Fonts für die Brotschrift sowieso der Fall. Aus solchen Fonts können gefahrlos *Sonderzeichen und Symbole* verwendet werden, da diese korrekt kodiert sind.

Wird bei solchen Zeichen jedoch auf Symbolfonts, PI-Fonts oder ähnliches zurückgegriffen, sind deren Zeichen meist nicht UTF-8-kodiert. 

Bei der ITC Zapf Dingbats z.B. gibt es ein weißes Sternchen auf schwarzem Kreis (✪). Schon in InDesigns Glyphenpalette sieht man beim darüberfahren, dass es sich eigentlich um den Buchstaben J handelt (GID 43, Unicode 004A). Genau der wird dann auch im XML so ankommen und von den im ePUB verwendeten Fonts so dargestellt werden. Benutzt man stattdessen für das Symbol die DejaVu Sans (GID 4017, Unicode 272A) wird das Zeichen wahrscheinlich auch im ePUB ankommen. Und zumindest ist es im XML korrekt.

Deswegen ist es wichtig für solche Zeichen alternative, gut ausgebaute Fonts zu verwenden, die jene Zeichen an der korrekten Stelle hinterlegt haben. Beispielsweise sind »DejaVu Sans« oder »Linux Libertine« freie, gut ausgebaute Fonts.

Ist es nicht möglich partiell einen anderen Font zu verwenden, kann über ein Zeichen-Mapping nachgedacht werden für die verwendete Schrift. Das ist mit zusätzlichem Einrichtungsaufwand pro Schrift verbunden. Auch kann über eine (automatisierte) Ersetzung mit entsprechenden Abbildungen nachgedacht werden, was ebenfalls einen Einrichtungsaufwand pro Font bedeutet. Die Daten verschlechtern sich aber dadurch, wenn im XML ein Bild statt eines Zeichens hinterlegt ist.

table{ width:60%;}.

|{background-color:#96D945;}. *Tipp* |

| Wenn es das Zeichen zwar in einer anderen Schrift richtig kodiert gibt, aber die Entsprechung nicht zum umgebenden Font passt, dann:

  – Für Print als Pfade umsetzen und mit bedingtem Text @PrintOnly@ versehen

  – Zusätzlich für die Konvertierung das Zeichen aus der DejaVu setzen und als @EOnly@ definieren |

h3. OpenType-Varianten

Bei der Benutzung dieser Varianten wird wahrscheinlich nicht dieselbe Repräsentation wie im InDesign-Dokument weitergereicht.

h3. Sonderfarben

Sollen Farbdefinitionen aus InDesign mitgenommen werden, kann grundsätzlich mit CMYK- oder RGB-Prozessfarben gearbeitet werden. Andere Farbmodelle, z.B. LAB-Farben sind kaum sinnvoll zu überführen und führen zu Konvertierungsfehlern.

Für Pantone-C Volltonfarben wurde ein Mapping nach RGB hinterlegt. Die hinterlegten Werte sind ohne jede Gewähr.

h3. Unterstreichungen und Überstreichungen (Durchstreichung)

InDesigns Funktionalität zum Unterstreichen und zum Durchstreichen von Text kann grundsätzlich verwendet werden. Was jedoch nicht 1:1 transportiert werden kann, sind Versätze bei diesen Optionen. Eine Durchstreichung, die mit Versatz im InDesign-Dokument wie eine Linie darüber aussieht, wird im elektronischen Medium zu einer Durchstreichung, da es keine CSS-Eigenschaften gibt, die diesen Versatz repräsentieren können.

h3. Verschachtelte Formate

Einige Typen von verschachtelten Zeichenformaten werden von @transpect@ zur Zeit weiterverarbeitet, die meisten jedoch nicht.

Wenn die verschachtelten Formate durch die Trennzeichen:

* *Tabulator*, 

* *Harter Zeilenumbruch*,

* *Einzug bis hierhin*, 

* *Geviert*, 

* *Halbgeviert*, 

* *geschütztes Leerzeichen* 

oder die Option 

* *erstes Wort*

definiert wurden, setzt @transpect@ diese um. Alle weiteren Optionen sind jedoch nicht implementiert. Dazu gehört die Verschachtelung über *Einzelne Zeichen*, *Buchstaben*, *Ziffern* etc. In diesem Fall müsste das Zeichenformat manuell zugewiesen werden.

Auch *mehrere Verschachtelungen funktionieren nicht*.