Indexing mit Word. tredition, Hamburg 2020.
344 Seiten. ISBN-13: 978-3-7439-8319-9.
Darin geht es in mehreren, zum Teil längeren Abschnitten um die Frage, wie funktionale Indexe bei der Erstellung von E-Books aus Word heraus erzeugt werden können.
Einen Ausschnitt aus dem Buch, in dem einige Aspekte zu funktionalen Indexen beschrieben werden, finden Sie hier.
Nähere Information zum Buch insgesamt: Beitrag „Indexing mit Word“.
]]>Schauen wir uns zunächst die wichtigsten E-Book-Formate an.
Der E-Book-Markt wird von drei Formaten beherrscht:
PDF ist genau genommen kein E-Book-Format, sondern lediglich ein digitales Format, das auch auf E-Book-Readern dargestellt und gelesen werden kann. In ihm ist die Anordnung von Text und Bildern fixiert, PDFs sind standardmäßig nicht reflowable, sie passen sich nicht automatisch an die Bildschirmgröße an. (Auf die spezielle Variante von Reflowable-PDFs möchte ich hier nicht eingehen, weil sie in der Praxis keine große Rolle spielt.)
Die Reflowable-Formate sind EPUB und MOBI.
EPUB bedeutet „electronic publication“ und ist das Standardformat für E-Books. Es wird seit 2007 vom International Digital Publishing Forum (IDPF) entwickelt und angeboten (als offenes Format). Die aktuelle Version ist EPUB 3, wobei EPUB 2 noch eine weitaus größere Verbreitung hat (die meisten E-Books werden im EPUB-2-Format angeboten). Wer sicher gehen möchte, dass die erzeugten Daten auf allen EPUB-fähigen Readern korrekt dargestellt werden, sollte im Format EPUB 2 publizieren. Bis auf die E-Book-Reader von Amazon, kommt auf allen anderen Readern (z. B. Apple-, Kobo- und Tolino-Geräten) EPUB zum Einsatz.
MOBI ist ein Format, das ursprünglich von der Firma Mobipocket entwickelt wurde und das seit 2007 Amazon gehört; hier wurde es eine Zeit lang auch als AZW-Format vermarktet. Die Weiterentwicklung von MOBI nennt sich KF8 („Kindle Format 8“), sie ist von ihren Fähigkeiten her mit EPUB 3 vergleichbar. MOBI ist das Standardformat der Kindle-E-Book-Reader.
MOBI lässt sich ohne allzu große Probleme in EPUB konvertieren und umgekehrt.
Der weiche, moderierte Weg besteht darin, das E-Book-Zielformat (EPUB oder MOBI) zu erzeugen, indem ein Layoutprogramm wie InDesign oder ein professionelles E-Book-Programm wie Jutoh (www.jutoh.com) sozusagen als Moderator zwischengeschaltet wird (auf andere „Moderatoren“ wie beispielsweise Kindle Create möchte ich hier nicht eingehen). In diese Programme kann das Word-Dokument importiert werden. Dann wird mit den Mitteln, die solche Programme zur Verfügung stellen, das Layout gestaltet, und schließlich wird EPUB (im Falle von InDesign) oder EPUB und/oder MOBI (im Falle von Jutoh) ausgegeben. Mit einem Prüfprogramm (in Jutoh enthalten) kann zum Schluss noch gecheckt werden, ob die Daten technisch in Ordnung sind. Danach sollte das Ergebnis optisch in einem E-Book-Betrachtungsprogramm (Apple iBooks, Adobe Digital Editions und Kindle Previewer) sowie auf verschiedenen E-Book-Readern kontrolliert werden. Falls alles in Ordnung ist, kann das E-Book veröffentlicht werden. Der Weg besteht also im Wesentlichen aus den Schritten
Voraussetzung für diesen Weg sind zwei Dinge: Als AnwenderIn müssen Sie das jeweilige Programm besitzen, und Sie müssen es bedienen können. Das kann aus mehreren Gründen schwierig sein. Ein Layoutprogramm wie InDesign kostet pro Jahr mindestens 200 EUR (je nachdem, ob es als Einzelprogramm oder als Teil eines Design-Pakets gemietet und ob es monatsweise oder jahresweise bezahlt wird). Um mit InDesign umgehen zu können, müssen Sie Erfahrung mitbringen oder Seminare und Workshops besuchen. Jutoh ist im Vergleich dazu sehr günstig: Der Kaufpreis liegt zwischen 30 EUR (einfache Variante) und 80 EUR (professionelle Ausgabe). Um den Umgang mit Jutoh zu erlernen, empfiehlt es sich, das einführende Video auf der Jutoh-Seite anzuschauen, die Bedienungsanleitung zu konsultieren und Erfahrung anhand von Probe-Projekten zu sammeln – mit anderen Worten: Jutoh kann man sich selber beibringen. Mit technischen Details wie HTML oder XML müssen Sie sich in InDesign und Jutoh höchstens am Rande beschäftigen. Während mit InDesign sowohl Drucklayouts als auch E-Book-Layouts erzeugt werden können, ist Jutoh ein reines E-Book-Layout-Programm.
Der harte, direkte Weg ist dadurch gekennzeichnet, dass von Word aus gleich in HTML und XML eingestiegen wird. Jede/r professionelle Word-AnwenderIn ist, so möchte ich behaupten, in der Lage, HTML-Quellcode und XML-Quellcode zu verstehen und bis zu einem gewissen Grad damit umzugehen. Der Weg kann kostenlos oder zumindest sehr günstig sein, weil ausschließlich OpenSource- oder Shareware-Programme zum Einsatz kommen. Er besteht aus den folgenden Schritten:
]]>
Dabei entsteht eine HTML-Datei, die u. U. viele Word-spezifische Tags enthält. Die HTML-Datei muss bereinigt werden. Dazu wird die Datei am besten mit einem HTML-Editor (wie KompoZer) geöffnet, und es werden alle überflüssigen Tags entfernt (welche genau, ist ein anderes Thema). Die so bereinigte HTML-Datei kann dann mit den gängigen E-Book-Erzeugungs- und bearbeitungsprogrammen (Calibre, Sigil, Jutoh, Kindle Previewer) weiterverarbeitet werden.
Um möglichst sauberes HTML zu erhalten, muss die Word-Datei entsprechend vorbereitet sein. Und zwar sollte sie konsequent mit Formatvorlagen ausgezeichnet sein. Das gilt sowohl für Absatz- als auch für Zeichenformatierungen. Liegt eine solche „semantische“ Auszeichnung vor, ist die Bereinigung der HTML-Datei schnell erledigt.
Ideal wäre es, wenn aus einer Word-Datei sofort sauberes HTML herauskäme, das nicht oder nur wenig bereinigt werden müsste. Das klappt über einen kleinen Umweg. Es darf nicht direkt von Word aus im HTML-Format abgespeichert werden, sondern man muss die Word-Datei mit einem Konvertierungsprogramm umwandeln. Optimal für diesen Zweck geeignet zu sein scheint das Tool „Mammoth docx-converter“. In Kombination mit WordPress ist die Bedienung sehr einfach. Mammoth kann dort als Plug-In installiert und aufgerufen werden.
Die Installation geschieht von WordPress aus auf die übliche Weise (das ist jedem, der WordPress verwendet, klar).
Nach der Installation ist der Ablauf wie folgt:
Es sind zwei Anzeigen möglich: „Visual“ und „Raw HTML“. Zur Weiterverarbeitung kann der Raw-HTML-Code kopiert und in einen Texteditor oder einen HTML-Editor eingefügt werden.
Damit Mammoth die Word-Datei optimal konvertiert, muss ein Style-Mapping gemacht werden. Das heißt, man gibt an, aus welcher Word-Formatvorlage welches HTML-Element werden soll. Die Syntax ist (hier beispielhaft gezeigt):
p[style-name=’df_u1′] => h1
Hier wird aus der Word-Formatvorlage „df_u1“ das HTML-Element „h1“.
Für jede Word-Formatvorlage ist eine solche Konvertierungszeile anzugeben, und zwar einfach als normaler Text in einer .txt-Datei (am besten in Notepad). Die Datei wird unter dem Namen „style-map“ abgespeichert (an einem beliebigen Ort auf der Festplatte).
Damit Mammoth die Style-Map anwenden kann, muss sie in die Word-Datei eingebettet werden. Dazu einfach an die Dateinamenerweiterung .docx ein .zip dranhängen, dann dieses Archiv öffnen und
Dokument- und Formatvorlagen in Word 2016, 2013 und 2010. tredition, Hamburg 2017.
528 Seiten. ISBN-13: 978-3743968974.
Darin geht es an vielen Stellen um die Frage, was bei der Erstellung von E-Books aus Word heraus zu beachten ist.
Nähere Information: Beitrag „Dokument- und Formatvorlagen“
]]>Im Unterschied zu gedruckten Büchern fehlen den meisten E-Books zwei wichtige Eigenschaften:
Der wichtigste Grund für beide Versäumnisse ist der Verzicht auf die Nutzung von Nummern.
Es ist klar, dass es bei E-Books keine Seiten gibt und somit Seitenzahlen nicht verwendet werden können. Doch wenn weder im Inhaltsverzeichnis noch in einem evtl. vorhandenen Register Nummern angegeben werden, kann der Leser nicht einschätzen, was ihn erwartet:
Das sind nur zwei Fragen, auf die der Leser eines gedruckten Buches immer eine Antwort erhält, der Leser eines üblichen E-Books leider nie.
D. h., E-Books geben keine oder nur wenig Übersicht. |
Die meisten E-Books bieten darüber hinaus keinen Ersatz für die Kolumnentitel gedruckter Bücher. Das heißt aber, dass der Leser nicht erkennen kann, wo er sich gerade im E-Book befindet. Mit anderen Worten:
E-Books geben keine oder nur wenig Orientierung. |
Die übliche Information, die dem Leser zur Orientierung angeboten wird, ist eine eingeblendete Positionsangabe. Diese bezieht sich je nach Einstellung auf ein Kapitel oder das gesamte Buch. Es handelt sich dabei aber leider um Zahlenwerte, zu denen man als Leser keine Beziehung aufbauen kann. Absolute Positionsangaben (z.B. Position 5187) oder relative Werte innerhalb eines Kapitels (z. B. 3/16) oder bezogen auf den Umfang des gesamten Buches (z. B. 53%) sind inhaltslose Werte, geben dem Leser keinen Halt und keine Orientierung. Das Problem liegt darin begründet, das auf dem Bildschirm eines E-Readers immer nur ein einzelner Ausschnitt aus einem Buch zu sehen ist. Die Inhalte sind sequenziell hintereinander angeordnet: Blättert man weiter, verschwindet der erste Inhalt zugunsten des zweiten. Es fehlt die dritte Dimension des gedruckten Buches, die ständig die Information liefert, was hinter und vor dem Leser liegt. Wahrscheinlich kann dieses Problem erst mit ganz neuen Bildschirmtechniken gelöst werden.
Bis die zur Verfügung stehen, müssen Hersteller und Leser sich anders behelfen. Der Kindle-Reader und der Kobo-Reader zeigen ganz gute Ansätze dazu.
Die Kindle-Software für die zweite Generation des Kindle Paperwhite enthält die sog. Page-Flip-Funktion, mit der erstmals Orientierung in E-Books ermöglicht wird.
Bild 1: Im linken Teilbild ist die Ansicht wiedergegeben, die man erhält, wenn man beim Paperwhite auf den oberen Rand tippt. Der Titel des Buches wird oben angezeigt, der Kolumnentitel (hier „Traditional Uses“), also letztlich die Kapitelüberschrift, erscheint unten. Da es keine rechten und linken Seiten gibt, können sich im Kolumnentitel nicht Kapitelüberschrift und Unterkapitelüberschrift abwechseln (wie es bei gedruckten Büchern üblich ist). Das rechte Teilbild zeigt die Page-Flip-Funktion, zu der man gelangt, indem man das linke mit drei unterschiedlich dicken Strichen belegte Rechteck am unteren Bildschirmrand antippt. (Das rechte Rechteck am unteren Bildschirmrand führt zur sog. erweiterten Page-Flip-Funktion, mit der neun Seitenminiaturen angezeigt werden. Allerdings lässt sich der Text einer Seitenminiatur nur erahnen, wodurch der Orientierungseffekt wieder verloren geht.)
Das Besondere der Page-Flip-Funktion: Über dem aktuellen Text wird ein „Seitenkasten“ eingeblendet, in dem eine Seite verkleinert dargestellt wird. Hier kann nach rechts und links geblättert werden („Page Flip“), wobei jeweils der komplette Seiteninhalt lesbar zu sehen ist. Während des Blätterns bleibt der eigentliche Fokus auf der Seite mit dem aktuellen Text. Wird der Seitenkasten verlassen, befindet man sich wieder auf der Ausgangsseite, tippt man auf die Mitte des Seitenkastens, schließt sich der Kasten ebenfalls und die neue Seite ist jetzt im Fokus. Das Vorgehen hat etwas vom „Finger zwischen den Seiten lassen und gleichzeitig mit der anderen Hand weiterblättern“. Unterhalb des Seitenkastens ist ein rudimentärer Kolumnentitel (auf Basis des jeweiligen Kapiteltitels) zu sehen und darunter eine Navigationsleiste (Schieberegler). Alles zusammen vermittelt ein Grundgefühl dafür, wo man sich im Buch gerade befindet.
Auch beim Kobo Reader hat sich einiges getan. Wie beim Kindle Paperwhite wird am unteren Rand ein Kolumentitel gezeigt, der sich aus den Kapitelüberschriften speist. Allerdings ist dies – anders als beim Kindle – die Standardeinstellung, d. h., man muss nicht erst auf den oberen Rand oder irgendwo auf die Seite tippen:
Bild 2: Auf dem Kobo werden Buchtitel (oben) und Kolumnentitel (unten) standardmäßig angezeigt.
Ein Tap (engl. „Tipp“) auf die Buchseite bringt die Anzeige des Kolumnentitels zum Verschwinden und es kommen am unteren Rand einige interessante Navigationsfunktionen zum Vorschein:
Bild 3: Am unteren Rand werden Navigationsfunktionen gezeigt.
Bild 4: Detaillierte Information zum Kapitel sowie Navigations- und Sprungmöglichkeiten. Beispielsweise führt der Tap auf eine doppelte Pfeilspitze zum vorhergehenden oder nachfolgenden Kapitel.
Bild 5: Leseverlaufsübericht
Man sieht, wie lange man noch im aktuellen Kapitel lesen wird, welche Zeit voraussichtlich zum Lesen des nächsten Kapitels benötigt wird und (rechts unten) wie viele Minuten „übrig“ sind, bevor man das Ende des Buches erreicht. Links unten wird sogar eine Übersicht über die relativen Umfänge aller Kapitel des Buches gegeben.
Fazit: Die Hersteller sind durchaus bemüht, Hilfen bei Orientierung und Übersicht anzubieten. Genutzt werden dazu die Mittel, die digitale Medien zur Verfügung stellen, nämlich statistische Auswertungen. Das ist nicht übel, kann aber mit der Orientierung und Übersicht von analogen Medien (sprich: gedruckten Büchern oder aber auch PDFs) nicht mithalten.
Dazu muss an möglichst vielen Stellen in einem E-Book mit Nummern gearbeitet werden.
Die meiner Einschätzung nach einzig vernünftige Art von Nummern sind Absatznummern. |
Das Entscheidende ist, dass die Absatznummern offen gezeigt werden, und zwar
Damit die angezeigten Nummern den Lesefluss nicht unnötig stören, sollten sie in etwas kleinerer (und nicht besonders hervorgehobener) Schrift als eine Art Spitzmarken am Beginn der Absätze stehen. Außerdem müsste nicht unbedingt jeder Absatz nummeriert werden, die Nummerierung sollte vielmehr nach inhaltlichen Gesichtspunkten vorgenommen werden; mit anderen Worten:
Bei der Vergabe der Nummern sollte in Informationseinheiten gedacht werden. |
Mit diesen Nummern ist es dann wieder möglich,
Die Indexnutzung profitiert noch in anderer Weise davon: Kommt ein Leser vom Index zur Fundstelle im Text, geben die Nummern an den Absatzanfängen Orientierung, denn der Leser sieht sofort, ob er sich in der zugehörigen Informationseinheit befindet und wo diese beginnt und endet.
]]>Kurz gesagt: XML ist eine neutrale Auszeichnungssprache (synonym: Markierungssprache). Die Abkürzung bedeutet Extensible Markup Language.
Vor allem zum automatischen Verarbeiten von Inhalten!
Weil Computer – die führen die automatische Verarbeitung aus – den Sinn von Inhalten, insbesondere den Sinn von Inhalten mit Mustern nicht verstehen.
Prinzipiell ja. In der Verlags- und Lektoratspraxis spielt XML z. B. eine Rolle, wenn in Content-Management-Systemen gearbeitet wird oder wenn kleine E-Books individuell erstellt werden.
Eine Möglichkeit, mit Codierungen anzugeben,
– wie ein Text aufgebaut und
– wie er formatiert ist.
Man spricht manchmal auch von generischer Markierung.
– Weil solche auf dem WYSIWYG-Prinzip beruhenden Auszeichnungen in jedem Programm anders vorgenommen werden müssen und
– weil die Programme so abgekapselt sind, dass man die Inhalte von außen nur schwierig beeinflussen kann, was aber einer automatischen Verarbeitung zuwiderläuft.
Im Prinzip um ganz einfache Dinge: z. B. um die Hervorhebung von Textstellen mit dem Ziel, dem Leser mitzuteilen, dass solche Textstellen besonders wichtig sind. So wie oben die Wörter „neutrale Auszeichnungssprache“ und „automatisches Verarbeiten“. Der Leser kann außerdem an der unterschiedlichen Art der Hervorhebung (fett bzw. kursiv) erkennen, dass es sich anscheinend um verschiedene Typen von Mitteilungen handelt: fett bedeutet, hier wird auf einen wichtigen Fachbegriff hingewiesen, bei Kursivauszeichnung könnte es sich einfach um eine rhetorische Betonung handeln.
Nein, neben XML (oder auch SGML, Standard Generalized Markup Language) sind vor allem
zu nennen.
Beide sind aber
– weder so streng wie es für eine wirklich neutrale Auszeichnungssprache nötig ist
– noch lassen sie sich so einfach den jeweiligen Gegebenheiten eines Publikationsprojekts anpassen wie XML.
– XML eignet sich nicht nur zum Strukturieren von Publikationsprojekten, sondern auch zum Strukturieren von Computerprogrammen, m.a.W.: mit XML kann man programmieren! Das Office-Paket von Microsoft ist im Wesentlichen in XML programmiert.
– XML passt ideal zum modularen Konzept moderner Programmiersprachen: XML-Dokumente können selbst aus mehreren klar definierten Teilen („Objekten“) aufgebaut sein. Man spricht dann von OpenXML. Offen bedeutet in diesem Zusammenhang, dass jedes Einzelteil separat erzeugt und/oder verändert werden kann und erst die Summe aller Teile die eigentliche Dokumentdatei ergibt. Word und OpenOffice arbeiten nach diesem Offenheitsprinzip.
– Durch die Strenge – Auszeichnungen können nur in einer bestimmten Reihenfolge vorgenommen werden – ist der Aufbau von XML-Dokumenten ideal zum Austausch mit Datenbanken geeignet, weil die ebenfalls nach strengen formalen Kriterien aufgebaut sind.
Bild 1: Drei wesentliche Merkmale von XML: Neutralität, Strenge, Offenheit
Weiter zum Beitrag über XML-Workflows.
]]>Als Beispiel sei ein Register betrachtet, dessen Einträge in eine Datenbank eingegeben wurden. Ein Ausschnitt könnte innerhalb der Datenbank wie folgt aussehen:
Bild 1: Registerdaten, wie sie von einem Datenbankprogramm (hier: Excel als Datenbank) präsentiert werden. Zu sehen sind die RTF-Deklaration, Schrift- und Sonderzeichenbefehle sowie der Befehl für die Absatzmarke (\par).
Die Daten werden als reine ASCII-Daten exportiert, und die so entstandene .txt-Datei wird mit Word geöffnet.
Als Bild stellt sich der Weg wie folgt dar:
Bild 2: Publikation aus der Datenbank (Excel) über RTF nach Word.
Word erkennt, dass es sich um eine RTF-Datei handelt, konvertiert sie und stellt die Daten wie folgt dar:
Bild 3: Ansicht der konvertierten RTF-Datei direkt nach dem Umwandeln mit Word.
Wird die konvertierte Datei mit dem üblichen Speichern-Befehl gespeichert, erhält sie die Endung .rtf – es handelt sich um eine RTF-Datei. Im nächsten Schritt sollte sie im docx-Format gespeichert werden (per Speichern unter), damit sie als Word-Datei vorliegt und alle Word-Funktionen auf sie angewendet werden können. In der Word.Datei sind noch ein paar unschöne/falsche Stellen enthalten (z. B. separate Zeilen mit reinen Seitenverweisen oder f- und ff-Angaben mit einem Endash davor). Sie können mit einfachen Suchen/Ersetzen-Läufen bereinigt werden. Das Endergebnis ist dann:
Bild 4: Bereinigte, druckfertige Registerdatei. Diese Datei könnte z. B. in InDesign platziert und anschließend publiziert werden.
Wichtig zu wissen:
XML funktioniert prinzipiell sehr ähnlich. |
Basis von RTF ist eine Markierungssprache, die nur einfache (und daher leicht zu verstehende) Befehle enthält.
Wie bei fast allen „generischen“ Markierungssprachen besteht das wichtigste Prinzip darin, Anfang und Ende des „Wirkungsbereichs“ eines Befehls zu kennzeichnen. So kann z.B. die Kursivformatierung mit dem Befehl \i eingeleitet und mit \plain beendet werden:
Dies ist eine \i Probe\plain |
Dieser Text wird in konvertierter und damit formatierter Anzeige zu
Dies ist eine Probe |
Am einfachsten ist es, Wirkungsbereiche mit geschweiften Klammern zu umgeben:
„{“ eröffnet einen Bereich, „}“ schließt ihn ab (die Anführungszeichen dürfen nicht mitgeschrieben werden). |
Das vorstehende Beispiel ließe sich also auch schreiben als:
Dies ist eine {\i Probe} |
Das Ergebnis der formatierten Anzeige wäre dasselbe.
Man sagt auch, eröffnende und schließende geschweifte Klammer definieren eine Gruppe.
Nach jedem Befehl muss ein Leerzeichen stehen; es kann dann Inhaltstext folgen oder ein weiterer Befehl.
Jede RTF-Datei muss durch einen Befehl eingeleitet werden, der deutlich macht, dass es sich um eine RTF-Datei handelt (dies ist die sog. RTF-Deklaration): {\rtf1 Und jede RTF-Datei muss durch eine abschließende geschweifte Klammer beendet werden: } |
Eine sehr einfache RTF-Datei wäre also z.B.
{\rtf1 Dies ist eine {\i Probe} } |
Dieser Text kann in einem einfachen Text-Editor, z. B. dem in Windows enthaltenen Programm „Editor“ (unter „Zusatzprogramme“ zu finden), eingegeben und abgespeichert werden. Die abgespeicherte Datei erhält als Dateiendung automatisch .txt, also z.B. probe.txt. Man könnte nach dem Abspeichern die Endung in .rtf ändern, aber die Mühe der bewussten Auswahl des Formats muss man sich nicht machen, denn ruft man die txt-Datei mit Word auf, so erkennt das Programm wegen der RTF-Deklaration sofort, dass es sich um eine Datei mit RTF-Auszeichnung handelt. D. h. in Word wird sofort
Dies ist eine Probe |
angezeigt.
Um mehr Kontrolle über das Öffnen von Dateien zu haben, empfiehlt es sich, in den Word-Optionen die Checkmarke bei „Dateiformatkonvertierung beim Öffnen bestätigen“ (Word 2007 bis 2016) bzw. „Konvertierung beim Öffnen bestätigen“ (Word 2003 und älter) zu setzen.
Dann erscheint beim Öffnen der Datei probe.txt die Meldung
Bild 1: Meldung in Word beim Öffnen einer ASCII-Datei, die RTF-Befehle (insbesondere die RTF-Deklaration) enthält
Anhand dieser Meldung sieht man also direkt, dass Word die RTF-Codierung erkennt.
Würde in der gleichen txt-Datei der RTF-Eröffnungsbefehl fehlen, so erschiene das Fenster
Bild 2: Meldung in Word beim Öffnen einer ASCII-Datei, die reine Textdaten enthält
Wir wüssten damit, dass die zu öffnende Datei eine reine Text-Datei ohne Formatierung ist. Und das bleibt sie auch, wenn wir sie durch Drücken des OK-Buttons in Word öffnen. Die Codierungen sind zu sehen, weil sie nicht konvertiert werden:
Dies ist eine {\i Probe} } |
Würde in der Datei dagegen nicht die RTF-Deklaration, sondern die abschließende geschweifte Klammer fehlen, so erschiene folgende Word-Meldung:
Bild 3: Meldung in Word beim Öffnen einer ASCII-Datei, die zwar RTF-Daten enthält, in der aber die abschließende geschweifte Klammer fehlt
D. h., selbst so winzige Dinge wie eine fehlende geschweifte Klammer haben einen großen Effekt.
Merksatz:
Beim Umgang mit Dateien, die generische Markierungen enthalten, kommt es auf jedes einzelne Zeichen an! Doch nicht nur das Vorhandensein von Zeichen ist wichtig. Auch ihre Reihenfolge muss stimmen (z. B. Eröffnung und Ende). |
Befehl | Bedeutung |
{ | Eröffnung einer Gruppe |
} | Abschluss einer Gruppe |
\rtf | RTF-Eröffnungsbefehl |
\ansi | Befehl, der daraufhinweist, dass der Ansi-Zeichensatz verwendet wird |
{\fonttbl | Befehl, der daraufhinweist, dass mit der im Hintergrund liegenden „Zeichensatz-Tabelle“ gearbeitet werden soll. Word (oder auch z. B. ein Layoutprogramm) kann dann auf bestimmte Schriften zurückgreifen. |
{\f0\froman Times New Roman;} | Befehl für die Schrift Times New Roman |
\i | kursiv |
\b | fett |
\sub | tiefgestellt |
\super | hochgestellt |
\plain | Befehl zum Ausschalten einer Formatierung (wenn nicht mit Gruppierung, also mit geschweiften Klammern, gearbeitet wurde) |
\par | Befehl für die Absatzschaltung |
Dateien mit „harten“ Formatierungen lassen sich mit diesen Befehlen sehr einfach direkt in einem ASCII-Editor schreiben. Werden sie mit Word oder einem anderen Programm, das RTF verarbeiten kann, geöffnet, so werden die Formatierungen sofort korrekt umgesetzt und angezeigt.
Genutzt werden kann das z. B. beim Publizieren aus Datenbanken.
Wichtig zu wissen:
XML funktioniert prinzipiell sehr ähnlich. |
Angepasst an die Struktur entwickeln die Programmierer dann eine sog. Dokumenttypdefinition (DTD) oder ein Schema. Dabei handelt es sich um ein XML-Programm. Liegt ein solches Schema vor, können die Erzeuger (Autoren) und Bearbeiter (Lektoren) des Inhalts die Struktur der zu dem Projekt gehörenden Dokumente an dieses Schema anpassen. Das heißt, in der Regel sind wir Lektoren nicht für die Entwicklung eines Schemas zuständig, sondern wir wenden es an. Zum Glück müssen wir, um das zu können, nicht unbedingt XML-Experten werden. Die Anpassung eines Dokuments an ein vorgegebenes Schema (oder eine DTD) kann für uns einfach bedeuten, das Dokument in Word konsistent und konsequent auf Basis einer Dokumentvorlage auszuzeichnen, also Formatvorlagen anstelle von manueller („harter“) Formatierung anzuwenden. Eine auf diese Weise vorbereitete Word-Datei kann relativ problemlos in eine XML-Datei überführt werden. Dafür sind üblicherweise wiederum nicht wir, sondern Techniker zuständig. Ein Workflow, bei dem wir die Überführung der Word-Daten in XML schaffen können, selbst ohne tiefgehende XML-Kenntnisse, ist der E-Book-Workflow, auf den unten näher eingegangen wird.
Grundsätzlich muss nicht erst in Word hineingearbeitet werden, damit anschließend XML entstehen kann. Es ist auch möglich, sich als Autor oder Lektor sofort in XML-Daten zu bewegen. Auch dazu wird unten mehr gesagt.
Liegt eine XML-Datei vor, kann ihr Inhalt in den unterschiedlichsten Formaten publiziert werden. Diese Variabilität ist einer der großen Vorteile von XML und einer der Hauptgründe, weshalb sich XML in den letzten Jahren in der Verlagswelt durchgesetzt hat.
Damit der Inhalt der XML-Datei publiziert werden kann – in gedruckter oder digitaler Form –, wird noch eine weitere Komponente benötigt: ein sog. Stylesheet, genauer: ein Cascading StyleSheet, abgekürzt CSS. In einem solchen CSS wird beschrieben, wie die Inhalte einer XML-Datei am Bildschirm oder bei der Druckausgabe aussehen sollen. Zur korrekten Umsetzung der CSS-Beschreibungen braucht es darüber hinaus die sog. Extensible Stylesheet Language Transformations (XSLT). Und umgesetzt wird alles in XHTML (das X deutet an, dass es sich um HTML handelt, das aus XML heraus erzeugt wird). Schließlich wird im letzten Schritt aus XHTML normales HTML (zur Anzeige auf einem Rechner) oder EPUB (zur Anzeige auf einem E-Reader; EPUB = electronic publication) oder aber ein Format, das zum Drucken geeignet ist. Das hört sich nicht nur sehr technisch an, es ist genau das. Trotzdem brauchen wir Lektoren davor keine Angst zu haben, denn die meisten dieser Punkte werden uns von den Programmen, die wir verstehen und einsetzen können, abgenommen. Das trifft speziell auf die E-Book-Erzeugung zu – siehe unten.
Am Ende des XML-Workflows stehen also, um das noch einmal zu betonen, entweder digitale Anzeigedaten – HTML oder bestimmte XML-Varianten wie EPUB – oder druckfähige Daten, deren endgültiges Layout mit einem Layoutprogramm erzeugt wird. Die Konvertierung der XML-Daten in Layoutprogrammdaten ist nicht trivial; sie kann nur von Technikern vorgenommen werden. Die Gestaltung im Layoutprogramm ist dagegen eine Tätigkeit, bei der wir Lektoren durchaus wieder ins Spiel kommen können. Die eigentlichen Druckdaten sind dann meistens PDF-Dateien.
Der gesamte XML-Workflow mit seinen wichtigen Komponenten und Stationen wird in Bild 1 wiedergegeben.
Bild 1: XML-Workflow, der alle prinzipiell nötigen Komponenten zeigt.
Ein XML-Workflow, in dem wir Lektoren an fast allen Stationen beteiligt sein können, ist der, der zu E-Books führt.
Wir könnten z. B. eine Word-Datei, die wir bearbeitet haben, einfach als XML-Datei abspeichern. Beim Speichervorgang wendet Word von ganz allein (und bei OpenOffice geht es analog) die Transformation auf Basis eines (von Microsoft) eingebauten Schemas an. Auch ein CSS wird automatisch in die XML-Daten eingebaut. Doch trotz all dieser Hilfen, die Microsoft vorgesehen hat, wären die meisten von uns überfordert, aus diesen Word-XML-Daten E-Book-Daten, letztlich also EPUB, zu erzeugen. Wir können Word-XML zwar grundsätzlich verstehen, die Weiterverarbeitung sollten wir aber lieber Technikern überlassen.
Textverarbeitungsprogramme, nicht nur Word, sondern auch z. B. OpenOffice, bieten zum Glück noch andere, einfachere Wege (zumindest für uns Lektoren einfachere) hin zum EPUB-Format. Die wichtigste Möglichkeit besteht darin, die Word-Datei nicht als XML-Datei, sondern im HTML-Format abzuspeichern und daraus im nächsten Schritt dasjenige XML zu machen, das für die weitere Verarbeitung benötigt wird. Bei der E-Book-Erzeugung wird oft genau dieser Weg – von Word über HTML zu XML – gegangen. Der XML-Workflow für E-Books, den Lektoren beschreiten können, sieht grundsätzlich wie folgt aus:
Bild 2: E-Book-XML-Workflow in der Hand von Lektoren. Ausgangspunkt ist eine Word- oder InDesign-Datei, die zunächst in HTML und dann z.B. in EPUB umgewandelt wird. Bei InDesign und einigen Textverarbeitungsprogrammen (wie OpenOffice oder Papyrus Autor) ist auch eine direkte Umwandlung in EPUB möglich. Im Bild wird zusätzlich der Print-Zweig (über PDF) gezeigt.
Bei diesem vereinfachten Workflow haben wir erst einmal nichts mit DTDs, Schemas, CSS, XSLT, ja nicht einmal direkt mit XML-Codierung zu tun. Und trotzdem erzeugen wir XML, denn eine EPUB-Datei ist eine XML-Datei (genauer: besteht aus [mehreren] XML-Dateien).
HTML aus Word erhalten wir durch den einfachen Befehl „Speichern unter“ HTML:
Bild 3: Abspeichern einer Word-Datei im HTML-Format. Wählen sollte man „Webseite, gefiltert“, weil Word dann gleich überflüssigen Code entfernt.
Die so erzeugte HTML-Datei können wir mit einem einfachen HTML-Programm (wie NVU) nachbearbeiten (dann müssten wir uns natürlich etwas mit den HTML-Codierungen befassen) oder aber direkt in ein Programm wie das leicht zu handhabende Calibre einladen, das die weitere Umwandlung in EPUB mehr oder weniger automatisch übernimmt. Ist die Word-Datei gut vorbereitet (also konsequent und konsistent mit Formatvorlagen ausgezeichnet) liefert dieser XML-Workflow sofort brauchbare Ergebnisse. Der Grund dafür, dass das funktioniert, besteht u. a. darin, dass Word beim Abspeichern als HTML-Datei automatisch sowohl ein bestimmtes vorgegebenes Schema anwendet als auch ein brauchbares CSS erzeugt.
Allerdings sind die Ergebnisse noch nicht optimal. Man könnte eine solche Datei zwar veröffentlichen, aber man würde ihr das „Quick-and-Dirty-Verfahren“ ansehen. Um eine halbwegs professionell wirkende EPUB-Datei zu erhalten, sollte sie mit einem EPUB-Programm nachbearbeitet werden. Optimal dazu geeignet ist das kostenlos einsetzbare Programm Sigil. Man kann auch Calibre umgehen und die HTML-Datei direkt mit Sigil öffnen; die dabei halb- oder vollautomatisch entstehende EPUB-Datei kann mit Sigil weiterbearbeitet, geprüft und fertiggestellt werden.
Im Bild der verwendeten Programme könnte ein typischer XML-Workflow für Lektoren also wie folgt aussehen:
Bild 4: Eingesetzte Programme von Word zur EPUB-Datei
Natürlich gibt es zu den einzelnen Schrittten einiges zu sagen. Die Details werden in anderen Beiträgen beschrieben.
Als Lektoren können wir aber auch in andere XML-Workflows eingebunden sein. Der oben beschriebene Workflow von Word zum E-Book (im EPUB-Format) weist aus technischer Sicht zwei Merkmale auf:
Denkbar sind auch andere Varianten.
So kann z. B. gleich im XML-Format begonnen werden. Das nennt sich dann XML-First. In der Praxis heißt das, dass man als Lektor direkt in einem XML-Editor arbeitet, und nicht in Word. Typische XML-Editoren sind der PTC Arbortext Editor, XMLSpy oder Oxygen, um die großen und teuren zu nennen. Ein kleinerer Editor ist editix. Prinzipiell kann jeder „normale“ ASCII-Editor (z. B. Notepad++) zur Eingabe und zum Bearbeiten von XML-Code verwendet werden, allerdings stehen dann keine Komfortfunktionen wie das Ein- und Ausblenden von Elementen oder Attributen zur Verfügung, sondern man muss im rohen Code arbeiten. Bei den Projekten, die uns üblicherweise angeboten werden, arbeiten wir in einem der genannten großen XML-Editoren. Sie sind oft noch in ein Content-Management-System (CMS) integriert.
Kurz ausgedrückt: Die Arbeit in einem CMS bedeutet nichts anderes als XML-First! |
Aus einem CMS heraus können verschiedene Ausgaberichtungen angefahren werden: Word, PDF, Layoutprogramm (wie InDesign oder FrameMaker) und auch EPUB.
Ein CMS zeichnet sich gegenüber einem puren XML-Editor u. a. dadurch aus, dass mehrere spezielle DTDs (verlags- oder projektspezifisch) hinterlegt sind und verschiedene Cascading Style Sheets (CSS) angesprochen werden können. Sowohl die DTDs als auch die CSS sind von Programmierern angelegt worden – als Lektoren brauchen wir uns dazu keine Gedanken zu machen. Wir bekommen von der Existenz dieser XML-Basis-Bestandteile oft gar nichts mit.
Dass eine DTD „wirkt“, spürt man allerdings u. a. daran, dass bestimmte Formatierungen, die man vielleicht vornehmen möchte, nicht funktionieren, weil sie in der DTD, die die Strukturregeln für die Dokumente vorgibt, als verboten deklariert wurden. Ein Verbot könnte z. B. lauten: Innerhalb eines Einleitungstextes kann keine Zwischenüberschrift eingebaut werden. Blinkt der Cursor also gerade in einem Absatz, der als Einleitungstext formatiert wurde, so haben wir keinen Zugriff auf das Überschriftformat „Zwischenüberschrift“ (das in einem Projekt natürlich auch einen anderen Namen haben kann, z.B. „ubzw“ oder wie auch immer). Nur zum Vergleich: in Word könnte an jeder beliebigen Stelle eines Textes jede beliebige Überschrift eingebaut werden.
Vom Vorhandensein eines Cascading Style Sheets spüren wir tatsächlich nichts. Man kann nur indirekt auf die Existenz schließen: Meist sind im Content-Managament-System Ausgabebefehle einprogrammiert: Auf Knopfdruck lässt sich PDF erzeugen oder man kann Daten im InDesign-Format ausgeben usw. Das alles klappt nur, weil ein entsprechendes Cascading Style Sheet vorhanden ist.
Aber auch, wenn man nicht in einem CMS, sondern in einem reinen XML-Editor arbeitet, können DTDs und Cascading Style Sheets hinzugeschaltet werden (und haben dann im Grunde den gleichen Effekt wie in einem CMS).
Wenn man von irgendwoher zu XML kommt, sollte es doch auch möglich sein, den umgekehrten Weg zu beschreiten, oder? Ja, prinzipiell geht auch das.
Folgende zwei Gründe (wahrscheinlich gibt es noch mehr) können für eine sinnvolle Rückkonvertierung von XML z. B. zu Word oder InDesign ins Feld geführt werden:
Die Rückkonvertierung ist eine komplexe Angelegenheit, die nur von Experten (Satzunternehmen und Programmierern) vorgenommen werden sollte. Aber es gibt etliche Unternehmen, die diese Dienstleistung anbieten.
Wir Lektoren haben mit dem rein technischen Prozess der Rückkonvertierung wieder nichts zu tun, aber uns wird vielleicht ein Word-Dokument vorgelegt, das auf diesem Weg entstanden ist. In der Regel gibt es dann eine Dokumentvorlage, mit der das Dokument zu verbinden ist. Die Dokumentvorlage spiegelt die DTD und das Cascading Style Sheet wider, auf deren Basis die XML-Daten abgelegt waren oder aber – und das ist ja gerade der große Vorteil – auf deren Basis die zukünftige Ausgabe des Buches erzeugt werden soll. Aus der Word-Datei könnte dann wieder das neue XML entstehen, das sowohl zum Publizieren als auch zum erneuten Archivieren verwendet wird.
]]>