PDF zu ePUB Konvertierung Mac

PDF zu ePUB KonvertierungDie PDF zu ePUB Konvertierung auf dem Mac unterscheidet sich von den nötigen Schritten nur unwesentlich von der Konvertierung auf Windows-Systemen. Allerdings stehen uns auf Unix-Systemen mehr und andere Tools zur Verfügung, als unter Windows. Unter Windows brauchen wir einen mächtigen Editor, während uns Unix für die vielen anfallenden Aufgaben “Spezial-Tools” zur Verfügung stellt.

PDF zu ePUB Konvertierung Arbeitsschritte

  1. Text (und Bilder) aus PDF extrahieren
  2. Text aufbereiten (Trennzeichen, Seitenzahlen, etc.)
  3. Text auszeichnen (HTML erstellen)
  4. ePUB-Dateien erstellen (opf, etc.)
  5. Archiv erstellen (ePUB-Zip)

Für den ersten Schritt benötigen wir ein Tools, das nicht standardmäßig auf dem Mac vorhanden ist – nämlich XPDF bzw. pdftotext und pdfimages aus dieser Bibliothek. Die Binaries für Mac findet man unter http://www.foolabs.com/xpdf/download.html.

Laden Sie das dort angebotene Archiv herunter und folgen Sie der Anweisung in der ReadMe. Hier die wichtigsten Schritte:

Entpacken Sie das Archiv:

tar -xzvf xpdfbin-mac-3.04.tar.gz

Sie können jetzt das Archiv löschen ( rm xpdfbin-mac-3.04.tar.gz ).

Kopieren Sie die benötigten Dateien in das vorgesehene Verzeichnis.

sudo cp pdftotext /usr/local/bin 
sudo cp pdfimages /usr/local/bin 
sudo cp pdftotext.1 /usr/local/share/man/man1
sudo cp pdfimages.1 /usr/local/share/man/man1

Wenn alles richtig gelaufen ist, sollte dieser find-Befehl Ihnen 4 Dateien listen.

sudo find /usr/local -type f -name 'pdf*'
/usr/local/bin/pdfimages
/usr/local/bin/pdftotext
/usr/local/share/man/man1/pdfimages.1
/usr/local/share/man/man1/pdftotext.1

Das war schon alles an externen Tools, was Sie benötigen. Den Rest bringt Unix mit. Sie können jetzt den Text aus dem PDF extrahieren.

pdftotext -enc UTF-8 -raw PdfDatei.pdf TextDatei.txt

Wir benötigen den Text UTF-8 kodiert und wir wollen die Formatierung des PDF beibehalten. Dies geschieht über die Schalter -enc und -raw. Das Resultat wird in die, von uns angegebene, Textdatei geschrieben. Falls Sie auch noch das Coverbild extrahieren wollen, verwenden Sie folgenden Befehl:

pdfimages -f 1 -l 1 -j  PdfDatei.pdf cover

Dies extrahiert die Bilder des PDFs.

Der schwierigste Schritt bei der PDF zu ePUB Konvertierung und der Schritt, wo “vollautomatische Programme”, wie z.Bsp. Calibre versagen, ist die Aufbereitung des Textes. Hier zeigen Unix-Systeme ihre volle Stärke, da es für jede Aufgabe in Zusammenhang mit Text ein Spezial-Tool gibt. Falls Sie einmal sehen wollen, was Ihr Mac an Tools zu bieten hat, können Sie folgenden Befehl eingeben:

compgen -c | sort -f | more

Dies listet ihnen alphabetisch alle Tools (und der Großteil bezieht sich auf Textarbeiten).

Warum ist die Textaufbereitung so schwierig? PDF ist ein Format, dass seitenbasiert ist und mit fixen Abmessungen arbeitet. ePUB basiert auf HTML und basiert auf “flow layout”. Wir haben keine Kontrolle über die Laufweite und Trennung von Text. D.h. wir müssen Worttrennungen rückgängig machen, Leerzeilen und Seitenzahlen entfernen.

Hier ein Beispiel eines Textes, der mittels pdftotext aus einem PDF extrahiert wurde:

eingerichtet. Mit einem schmalen Klappbett hoch oben
an der Längswand diente er auch als gelegentliches Heim
für den Administrator selbst.
Vom Fenster des Hauptbüros sah Dill über den Fluß
hinweg auf die Stadt hinüber, die wie ein konischer Bie-
nenkorb über dem Festland hing. An den meisten Tagen
zu bedrängt, um sie zu betrachten, sah er sie dennoch
gelegentlich, und jetzt mit neuen Augen.
Sie war gut proportioniert. Zu ihrer Blütezeit wäre sie
eindrucksvoll gewesen. Es gab eine hübsche Auswahl an
8
farbigen Oberflächen – stehende Rechtecke in Kobalt-
blau, horizontale Blöcke in Blaßgelb, aufblitzende Ein-
schiebungen in Zinnoberrot. Selbst jetzt glitzerte und
funkelte ihr Glas in der spröden Aprilsonne. Magische

Hier sieht man schon fast alle anfallenden Arbeiten. Wir haben eine Seitenzahl (8), die entfernt werden muss. Wir haben Worttrennungen (Bie-nenkorb). Wir haben Zeilenumbrüche, die entfernt werden müssen und wir haben Zeilenumbrüche (Absätze), die erhalten werden müssen. Oftmals haben wir auch noch Text, der vor oder nach dem eigentlichen Inhalt steht und entfernt werden muss.

Um sich Text am Anfang einer Datei oder am Ende einer Datei anzusehen bieten sich die Tools head und tail an.

head -n 60 TextDatei.txt

liefert die ersten 60 Zeilen der Datei. Kombiniert man diesen Befehl mit einem Tool, wie nl, das Zeilen numeriert, dann sieht man auf einen Blick, welche Zeilen entfernt werden müssen.

head -n 60 matrix0.txt | nl -ba

Dies ist das richtige Vorgehen auf einem Unix-System! Versuchen Sie nicht alles mit EINEM Tool zu erledigen. Für jede Aufgabe existiert ein SPZIALIST, dem Sie diese Aufgabe übergeben können.

Wollen wir jetzt z.Bsp. die ersten 56 Zeilen entfernen und das Ergebnis in eine neue Textdatei schreiben, so können wir z.Bsp. tail verwenden.

tail -n +56 TextDatei.txt > TextDatei1.txt

Die “Spezialisten” haben unterschiedliche Vorgehensweisen. So gibt es Tools, die Dateibasiert sind, während andere Tools Zeilenbasiert (stream), oder Spaltenbasiert sind. Manche sind auf das Auffinden, andere auf das Ersetzen spezialisiert.

Bei dem Auffinden bestimmter Textstellen und der Verwendung von stream-Editoren, wie grep und sed kommen Sie nicht an regulären Ausdrücken vorbei.

Ich verwende für die Aufbereitung meiner Texte folgende Tools:

  • grep
  • sed
  • tr
  • cat
  • cut

und bei besonders schwierigen Stellen awk.

cat matrix1.txt | grep -v -e ^^L[0-9]*$
sed -e ':a' -e 'N' -e '$!ba' -e 's/-\n//g' TextDatei1.txt > TextDatei2.txt

Ich kann an dieser Stelle kein vollständiges Training zu diesen Tools oder der Verwendung von RegEx geben. Das Internet ist jedoch voll mit guten Tutorials zu all diesen Themen.

ePUB hat eine Obergrenze für Dateigrößen. Dies kann bedeuten, dass wir eine große Datei in mehrere kleinere Dateien (Kapitel) aufsplitten müssen. Hier hilft z.Bsp. der Befehl csplit.

Auch bei der Erstellung der ePUB-Dateien, wie Manifest oder Inhaltsverzeichnis helfen uns diese Tools.

ls chapter*.txt | grep -n '.*' | sed 's/\([0-9]*\):\(.*\)/<li><a href="\2">\1<\/a><\/li>/g'
ls chapter*.txt | grep -n '.*' | sed 's/\([0-9]*\):\(.*\)/<navPoint id="navPoint-\1" playOrder="\1"><navLabel><text>Kapitel \1<\/text><\/navLabel><content src="\2"\/><\/navPoint>/g'

Mit diesen Befehlen können wir aus unseren Kapiteldateien Inhaltsverzeichnis-Einträge erstellen.

Für das Erstellen des Archivs können wie die eingebaute zip-Funktion verwenden. Wichtig hierbei ist, dass Mac-spezifische Dateien exkludiert werden.

Wer ernsthaft PDF zu ePUB Konvertierung auf dem Mac vornehmen will und dessen Qualitätsanspruch durch Calibre oder andere Tools nicht befriedigt wird, kommt nicht daran vorbei sich mit den Unix-Tools und RegEx auseinanderzusetzen. Wichtig hierbei:

do one thing and do it well!

Dies ist die Unix-Philosophie und der sollten Sie auch bei PDF zu ePUB Konvertierung folgen.

 

 

iBooks Buecher finden

iBooks Buecher findenViele Leute beschweren sich über iBooks in OS X – Ich persönlich finde iBooks gut, verstehe aber, wenn Leser ihre Bücher auf andere eReader übertragen wollen und deshalb in iBooks Buecher finden müssen. Die Bücher liegen ziemlich versteckt unterhalb der Library des Anwenders. In meinem Fall also unter Users/hpv/Library/…

Dort liegen die Bücher zwar entpackt, aber leider nicht unter ihrem ursprünglichen Dateinamen. Wenn Sie ein ls -p1 durchführen, sehen Sie wahrscheinlich eine Liste, ähnlich dieser:

082355E368BAA753CBCB09F48A635854.epub/
09E794038392833DDACAFA3BA040A40B.epub/
431338616.epub/
462973552.epub
482091957.epub/
498143383.ibooks/
4EDE3AB4ECA3306014A63FD793201B88.epub/
556528048.ibooks/
Books.plist
C2CDE1BCE7F73D6813F736B87F578E70.epub/
E844F4CAEC257D32E033346D1EBAB505.epub/
EE4B77F02315AE6AA1E12F73FBE47AC4.epub/
EF75403309D77F35F57F527948AF6B6F.epub/
F0811A5279034C3C421CF11D337F61E6.epub/
F1C796204FA4B6009EEF02E6997EE0C3.epub/
FB8E1A812603D7DFA53305C53C7A6E12.epub/

Diese Ordner repräsentieren Ihre Bücher und beinhalten die Content-Dateien Ihrer Bücher. Uns interessiert jedoch die Books.plist. Diese liegt bei Ihnen wahrscheinlich in binärer Form vor. Dies ist aber kein Problem, da uns OS X ein Tool für die Konvertierung zur Verfügung stellt. Falls Sie sicher gehen wollen, machen Sie eine Kopie dieser Datei und konvertieren diese dann mit dem Befehl:

plutil -convert xml1 Books.plist

Damit liegt die plist nun als XML-Datei vor und kann von uns ausgelesen werden. Wir wollen den Titel unseres Buches diesen nichtssagenden Ordnernamen zugeordnet haben.

Die plist verfügt hierfür über zwei Key/Value-Einträge, die uns diese Information geben.

<key>itemName</key>
 <string>Die geheimnisvolle Insel</string>
 <key>path</key> <string>/Users/hpv/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books/4EDE3AB4ECA3306014A63FD793201B88.epub</string>

Der itemName repräsentiert den Buchtitel und path stellt uns den Ordnernamen zur Verfügung.

Um an diese Informationen zu kommen, verwenden wir zwei xPath-Ausdrücke und das Tool xmllint.

cat iBooks-Books.plist | xmllint --xpath  "//key[text()='itemName']/following-sibling::string[1]/text() | //key[text()='path']/following-sibling::string[1] " -

Dies liefert uns Titel und Ordnername. Leider ist das Resultat eine lange Zeile. Um das ganze in eine CSV-Darstellung zu überführen, können wir sed verwenden:

sed 's/<string>\/Users\/hpv\/Library\/Containers\/com.apple.BKAgentService\/Data\/Documents\/iBooks\/Books\//;/g' | sed 's/<\/string>/$/g'

Dies ersetzt den langen Pfad und fügt die Zeichen $ und ; als Delimiter ein. Jetzt können wir Zeilenumbrüche mittels tr einfügen, die Liste sortieren und in die Datei buecher.csv schreiben.

tr $ '\n' | sort > buecher.csv

Hier der gesamte Befehl am Stück:

cat iBooks-Books.plist | xmllint --xpath "//key[text()='itemName']/following-sibling::string[1]/text() | //key[text()='path']/following-sibling::string[1] " - | sed 's/<string>\/Users\/hpv\/Library\/Containers\/com.apple.BKAgentService\/Data\/Documents\/iBooks\/Books\//;/g' | sed 's/<\/string>/$/g'| tr $ '\n' | sort > buecher.csv

Jetzt besitzen wir eine CSV-Datei mit Titel-/Order-Kombinationen:

20000 Meilen unter dem Meer;B69FFEA795D964E39A488A7A18047CB2.epub
 Die Pforte;415428079.epub
 Die geheimnisvolle Insel;4EDE3AB4ECA3306014A63FD793201B88.epub
 ...

In iBooks Buecher finden ist schwierig und aufwendig, aber nicht unmöglich. Wer sich mit obigen Befehlen schwer tut, sollte sich die Man-Pages dieser Tools ansehen.Die xPath-Syntax kann man sich unter http://www.w3schools.com/xpath/ näher ansehen.

Hoffe, dies hilft denjenigen, die Ihre ePubs aus iBooks übertragen wollen.

ePUB Titel extrahieren

ePUB Titel extrahierenEs gibt immer wieder Anfragen, wie man aus einem ePUB Titel extrahieren kann, bzw. die wichtigsten Daten mittels eines “Scripts” ausliest. Die wichtigsten META-Daten zu einem Buch stehen in der Datei content.opf. Wo diese genau liegt und wie sie genau heisst (content.opf ist nur eine Übereinkunft, aber nicht zwingend), wird steht in der container.xml unter META-INF. Dennoch kann man Dank einiger Unix-Befehle aus ePUB Titel extrahieren. Auf dem Mac verwenden wir die Befehle:

  • unzip
  • grep
  • cut

Unzip kann nicht nur ein ganzes Archiv entpacken, sondern auch einzelne Dateien. Dies muss nicht zwingend auf der Festplatte erfolgen, sondern man kann den Inhalt der Datei an stdout (also unser Terminal) ausgeben.

unzip -p "Raum-Geier - Cleve Cartmill.epub" "*.opf"

Dieser Befehl entpackt alle .opf-Dateien des Buches Raum-Geier – Cleve Cartmill.epub und schreibt das Ergebnis mittels des Schalter -p in die Konsole. Sollte das resultierende Dokument nicht sauber formatiert sein (wir benötigen die Elemente jeweils in einer Zeile), dann kann man das Ergebnis zu xmllint weiterleiten (pipe). Der Strich am Ende bedeutet “nimm XML von stdin”.

xmllint --format -

In der Regel steht der Titel in einem Element mit dem namespace-Kürzel dc. Nach diesem Eintrag suchen wir mit Hilfe von grep.

grep "dc:title"

Dieser liefert uns folgende Zeile:

 <dc:title>Raum-Geier</dc:title>

Diese Zeile geben wir an das Tool cut weiter. Hier geben wir als Delimiter (Spaltentrenner) mittels option -d zuerst das schliessende > ein. Damit wird der Text an dieser Stelle geteilt, so dass wir folgende Spalten (Felder) bekommen.

<dc:title       Raum-Geier</dc:title

Wir nehmen die zweite Spalte über den Schalter -f2 und geben diese erneut an cut. Diesmal teilen wir bei < und nehmen die erste Spalte (-f1). Damit haben wir unseren Titel.

Hier der Befehl in seiner Gesamtheit:

unzip -p "Raum-Geier - Cleve Cartmill.epub" "*.opf" | grep "dc:title" | cut -d'>' -f2 | cut -d'<' -f1

Das gleiche können wir auch für den Autor durchführen. Hierfür ersetzten wir lediglich dc:title durch dc:creator. Hier können allerdings mehrere Zeilen zurückkommen, da es mehrere “Rollen” von contributors gibt.

Wer also schnell ePUB Titel extrahieren will, kann dies auf System, die unzip, grep und cut unterstützen in einem Einzeiler vornehmen, ohne das gesamte Buch in einen Ordner zu entpacken und die Dateien manuell auszulesen.

Hier zeigt sich die Stärke von Unix. “Mach genau eine Sache richtig und verwende Text, wo immer möglich”.

 

 

lilypond Rhythmusgitarre

Man kann in lilypond Rhythmusgitarre darstellen und auch entsprechend den eigenen Bedürfnissen anpassen. Allerdings sind die Methoden, die man benötigt, wenn es an das “finetunig” geht, in der Dokumentation überall verstreut. Deshalb möchte ich hier zeigen, wie ich in lilypond Rhythmusgitarre Code angepasst habe.

lilypond Rhythmusgitarre ErgebnisDas Beispiel ist aus einer professionell gemachten Schule für Rhythmusgitarre. Der Autor zeigt hier unterschiedliche Rhythmus-Pattern, die auf 2-Beat basieren. Ihm war wichtig zu zeigen, dass der Arm durchschwingen soll. Deshalb hat er auf den ersten Beat den upstroke in Klammern gesetzt. Da es sich um ein Fragment handelt und nicht um einen 2/4-Takt, hat der Autor auf Metrum und Schlüssel verzeichtet. Das Original kommt diesem (in Lilypond erzeugtem Ergebnis sehr nahe). Ich weiss nicht in welchem Programm der Autor die Pattern erstellte – ich jedenfalls wollte es in Lilypond umsetzen.

lilypond Rhythmusgitarre Symbole

Lilypond bietet (von Haus aus) schon die Symbole für die Darstellung von Rhythmusgitarre. Die Schlagrichtung wird über die Violinzeichen \downbow und \upbow erzeugt und die Noten über ein einleitendes \improvisationOn. Ohne Anpassungen ist das Ergebnis jedoch noch nicht entsprechend der Vorgabe. Die Zählzeiten wurden als “lyrics” umgesetzt.

lilypond Rhythmusgitarre ohne Anpassung

Die Lyrics sind zentriert. Repeat volta setzt keinen Taktstrich am Anfang und die Noten sind etwas gedrängter und die Schlagsymbole sehr prominent. Upbow und Downbow können auch nur einzeln vergeben werden.

<<
 \new Voice ="slash" \with {
 \consists "Pitch_squash_engraver"
 } \relative c'' {
 \improvisationOn
 \time 2/4 
 \repeat volta 2 {
 c4 \downbow c8 \downbow c \upbow 
 }
}
 \new Lyrics {
 \lyricsto "slash" {
 "1 (&)" "2" "&"
 }
}
>>

Um zum gewünschten Ergebnis zu kommen, habe ich das repeat durch manuelle Taktstriche ersetzt, die Notenhälse verlängert und die Schlagrichtung in Markup umgesetzt.

up=\markup { 
 \halign #-1
 \teeny \musicglyph #"scripts.upbow" 
}
down=\markup { 
 \halign #-1
 \tiny \musicglyph #"scripts.downbow"
}
du=\markup {
 \override #'(font-size . 0)
 \left-align
 \tiny { \musicglyph #"scripts.downbow" } \concat { \raise #.2 \small ( \teeny { \musicglyph #"scripts.upbow" } \raise #.2 \small ) }
}
\markup { \line { \teeny { \bold { 2 Beat \concat { 8\super \lower #0.9 th} Note Pattern "#1" }}}}
\markup { \vspace #0.5 } 
<<
 \new Voice ="slash" \with {
 \override Stem.length = 6
 \override Stem.details.beamed-lengths = #'(4)
 \override NoteHead.font-size = #-2.5
 \consists "Pitch_squash_engraver"
 } \relative c'' {
 \improvisationOn
 \omit Staff.TimeSignature
 \omit Staff.Clef
 \textLengthOn 
 \bar ":..:"
 c4^\du c8^\down c^\up 
 \bar ":..:"
}
 \new Lyrics {
 \lyricsto "slash" {
 \tiny
 \once \override LyricText.self-alignment-X = #LEFT
 "1 (&) " "2" "&"
 }
}
>>

Statt downbow und upbow verwende ich jetzt mein eigenes markup down und up und auf dem ersten Beat du. Die Lyrics habe ich mittels override auf linksbündig gestellt. Auch die Attribute Notehead-font und Stem.length wurden mit override verändert. Vor allem das du musste angepasst werden, um die Klammergröße und die Symbolgrößen korrekt hinzubekommen. Um den Abstand zu verkleinern, habe ich Klammern und upbow über concate verbunden. Dies war auch bei der Überschrift nötig, da ein neuer Befehl ein Leerzeichen verursacht und so das th in 8th zu weit entfernt ist.

U1

Dies wird noch schlimmer, wenn man die Überschrift verkleinert.

U2

Das th entfernt sich noch mehr. Deshalb habe ich hier das th heruntergesetzt und über concate mit der 8 verbunden.

\tiny { \musicglyph #"scripts.downbow" } \concat { \raise #.2 \small ( \teeny { \musicglyph #"scripts.upbow" } \raise #.2 \small ) }

Zum Schluss habe ich noch den Notenabstand vergrößert und den linken Einzug des Notensystems auf 0 gesett.

\paper {
 indent=0.0
}
\layout {
 \context {
 \Score
 \override SpacingSpanner.base-shortest-duration = #(ly:make-moment 1/16)
 }
}

Man kann in lilypond Rhythmusgitarre darstellen, aber je nach Wunsch bedarf es doch des einen oder anderen finetunings. Diese verlangen Kenntnis der Attribute und die Verwendung von Markup. In Lilypond ist ALLES dokumentiert und sehr viel möglich. Für spezielle Formatierungen muss man sich jedoch an verschiedenen Stellen durch die Snippets bzw. die Dokumentation durcharbeiten. Hoffe, dieser Artikel erspart Ihnen langes Suchen und Sie können etwas davon für Ihre Formatierungen verwenden.

ePUB bash

Hier ein kleines ePUB bash Script, welches das Erstellen (zippen) eines ePUBs auf Unix-Systemen (hier OS X) erleichtert. Da bei einer wiederkehrenden Buchstruktur, die beiden Hauptordner META-INF und OEBPS und damit der Verweis auf die OPF-Datei in der content.xml immer gleich bleiben, kann man diese statischen Teile über ein bash-Script unter Verwendung enes here-documents leicht verwirklichen.

#!/bin/bash
 function makeMetaInf() {
 mkdir META-INF
 cat <<- _EOF_ > "META-INF/container.xml"
 <?xml version="1.0"?>
 <container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
 <rootfiles>
 <rootfile full-path="OEBPS/content.opf"
 media-type="application/oebps-package+xml" />
 </rootfiles>
 </container>
 _EOF_
}
function makeMime() {
 echo -n application/epub+zip >mimetype
}
function doZip() {
 zip -X0 $1 mimetype
 zip -Xur9D $1 META-INF OEBPS -x *.DS_Store
}
makeMetaInf
makeMime
doZip $1

Ich definiere drei Funktionen:

  • makeMetaInf = legt den Ordner META-INF im aktuellen Verzeichnis und darin dann die Datei content.xml an
  • makeMime = erzeugt die Mime-Datei (ohne Zeilenumbruch durch echo -n)
  • doZip = diese packt die mimetype und die Ordner OEBPS und META-INF eine Archiv. Als Name wird der String gewählt, der dem bash übergeben wird.

Ein Beispielaufruf wäre: epub.sh MeinBuch.epub. Dieser erzeugt dann ein Zip mit dem Namen MeinBuch.epub. Um dieses scipt überall verwenden zu können, habe ich es unter /usr/local/bin abgelegt und ausführbar gemacht.

eBook altdeutsch mit Noten

Bei meiner Suche nach freien Musikstücken (dachte an Volkslieder) stieß ich auf ein eBook altdeutsch geschrieben. “Volkslieder des deutschen Volkes”. Auf archive.org wurde dieses eBook auch als ePUB und mobi angeboten. Da mich natürlich brennend interessierte, wie altdeutsch und Noten in diesem ePUB umgesetz wurde, lud ich mir sofort das ePUB und das PDF herunter.

eBook altdeutsch auf archive.org

eBook altdeutsch archive.orgarchive.org selbst zeigt das eBook nicht in ePUB oder mobi an. Es handelt sich um ein eingescanntes Buch.

Beim Öffnen des ePUB in iBooks kam dann auch gleich die Ernüchterung (und ein bisschen Ärger)

eBook altdeutsch ePUB

VorredeSchon der reine Text der Vorrede (Vorwort) sieht fürchterlich aus. Hier wurde einfach eine pdf2txt, oder eine OCR-Software benutzt, ohne sich Gedanken über das Resultat zu machen. Entsprechend ist das Ergebnis. Natürlich kann die altdeutsche Schrift nicht so einfach in Text gewandelt werden. Ich verlange das auch nicht, aber dann sollte das Buch auch nicht als ePUB. mobi oder txt angeboten werden. Als nächstes wollte ich dann sehen, ob die Noten als Images extrahiert wurden und wie sie dann in das eBook eingebunden wurden. Deshalb ging ich zu der ersten Seite mit Noten. Dies ist das Kapitel 1 mit den Kinderliedern.

Lied in ePUBNoch schlimmer! Die Konvertierungssoftware hatte die Noten nicht als Bild erkannt und auch nicht extrahiert. Es versuchte korrespondierende Textzeichen zu finden und gab diese aus. Das Ergebnis ist natürlich nicht brauchbar.

Gut, das Ergebnis ist unbrauchbar, aber wer Kritik übt, sollte auch einen Weg zeigen, wie es denn hätte gemacht werden können. Kann man ein eBook altdeutsch und mit Noten als ePUB erstellen? Um diese Frage zu beantworten, habe ich einige Passagen des Buches als HTML umgesetzt um zu sehen, wie nah ich an das Original herankommen kann. Es geht nicht um eine 1:1 Kopie des Originals, sondern um den Stil des Buches und ob man ein eBook altdeutsch gestalten.

Angefangen habe ich mit der Titelseite:

PDF:

Titelseite PDFSchon die Titelseite verlangt einen Font in altdeutsch und einige Ornamente. Habe den Font Zentanar Fraktur für meine Versuche verwendet. Allerding hat dieser nur die runde Form des s (so wie es am Schluß eines Wortes verwendet wird) und nicht das lange s (das wie ein f aussieht). Das lange s habe ich deshalb über eine Unicode-Entity (ſ). Auch als Entity habe ich das Ornament Wellenlinie (〰) implementiert. Das kleine Bild im unteren Drittel wurde als Image eingebunden und auf das Ornament oben habe ich verzichtet.

Hier das Ergebnis meiner Titelseite in HTML.

HTML:

titel_hpv

Bin mit der Umsetzung zufrieden. Hier das CSS zu dieser Titelseite:

@font-face {
 font-family: deutsch;
 src: url(Zent____.ttf);
}
.deutsch {
 font-family: deutsch;
}
div.title p{
 text-align:center;
 margin: 12px;
 padding: 2px;
}
p.title1 {
 font-size: 200%;
}
p.title2 {
 font-size: 150%;
}

Der Font wurde font-face eingebunden und als Klasse zugreifbar gemacht. Dort, wo nötig, habe ich im Text das runde s durch die Unicode-Entity ersetzt.

Die nächste spannende Aufgabe war das Inhaltsverzeichnis. Hier das Original im PDF.

ToC PDF

Wichtig war mir, neben der altdeutschen Schrift, die Punkte als Füller und die römischen Ziffern für die Kapitel.

ToC HTML:

eBook altdeutsch ToCDa ich das I in diesem Font nicht für die römischen Ziffern verwenden konnte, habe ich auch hier Unicode-Zeichen verwendet. Da der Font diese unterstützt, war keine andere Font-Family nötig. Für die Punkte habe ich ein Pseudo-Element und das content-Attribut verwendet.

CSS:

ul.leaders8 {
 max-width: 40em;
 padding: 0;
 overflow-x: hidden;
 list-style: none
} 
ul.leaders8 li:before { 
 float: left;
 width: 0;
 white-space: nowrap; 
 content: 
 ". . . . . . . . . . . . . . . . . . . . "
 ". . . . . . . . . . . . . . . . . . . . "
 ". . . . . . . . . . . . . . . . . . . . "
 ". . . . . . . . . . . . . . . . . . . . "
 ". . . . . . . . . . . . . . . . . . . . "
 ". . . . . . . . . . . . . . . . . . . . "
 ". . . . . . . . . . . . . . . . . . . . "
 ". . . . . . . . . . . . . . . . . . . . ";
} 
ul.leaders8 li span:first-child {
 padding-right: 0.33em;
 background: white;
} 
ul.leaders8 li span:nth-child(2) {
 float: right;
 padding-left: 0.33em;
 background: white;
}

Durch diese CSS-Anweisungen wirken die Punkte, wie ein background. Die span-styles positionieren dann die Texte links und rechts.

<p><strong>&#x2160;. Kinderlieder</strong></p>
<ul class="leaders8">
  <li><span>Wiegenlieder</span><span>1&#x2013;20</span></li>
  <li><span>Kinder-Scherz u. Glaube</span><span>21&#x2013;54</span></li>
  <li><span>Kinderwün&#x017F;che</span><span>55&#x2013;58</span></li>

Das Vorwort sollte, wie im Original im Paragraphen-Anfang den ersten Buchstaben vergrößert anzeigen.

Vorrede HTML

Dies realisierte ich über folgende css-Klasse:

p[data-capital]:before {
 font-size: 150%; 
 content: attr(data-capital);
}

Dieser Klasse übergab ich dann im data-Attribut den Buchstaben.

Anmerkung: :first-letter wäre die bessere Alternative, falls content nicht unterstützt wird und der Anwender den Font wechselt. Da ein Font-Wechsel aber Probleme mit dem langen s mit sich bringt, gehe ich davon aus, dass der Font nicht gewechselt wird. Dieses Beispiel ist theoretischer Natur (was ist möglich) und sollte so nicht 1:1 übernommen werden.

Blieb noch die Einbindung der Noten. Hierfür habe ich ABC als Notations-Markup verwendet und ein SVG erzeugt, das ich nachträglich in ein PNG gewandelt habe. Um auch den Liedtext altdeutsch darzustellen, habe ich den Font auf dem System installiert und in der ABC-Datei über %%vocalfont "Zentenar Fraktur" eingebunden.

Hier das Ergebnis:

eBook altdeutsch NotenDas Ergebnis passt zum Gesamtbild. Die Notenlinien wirken zwar etwas zu “modern”, aber durch den Liedtext in altdeutscher Schrift wird es ausgeglichen.

Grundsätzlich kann man also auch solche Bücher ( eBook altdeutsch mit Noten) als ePUB bzw. in HTML umsetzen. Es macht etwas Mühe. Verlange nicht von archive.org, das dieser Aufwand dort getrieben wird, aber dann sollte man auch keine “ungeprüften” Konvertierungen anbieten.

Die Konvertierung von PDF zu ePUB verlangt immer ein manuelles Eingreifen und kann nicht voll automatisiert stattfinden, wenn ein gewisses Maß an Qualität verlangt wird!

Hoffe, der Artikel hilft bei der Umsetzung eigener Ideen. Falls noch Fragen zu eBook altdeutsch sind – hpv@leo.uberspace.de

cocoaspell deutsch

Um cocoaspell deutsch einzustellen, müssen ein paar Schritte ausgeführt werden.

Erfahrungsbericht cocoaspell deutsch einstellen

Die Installation von cocoaspell gestaltete sich einfach. Download von der Website und Installation des dmg. Leider beinhaltet diese Installation nur englische Wörterbücher (dictionaries). Also das deutsches Wörterbuch heruntergeladen.

Wie vorgeschlagen, das Archiv entpackt und den Ordner in /Library/Application Support/cocoAspell/ kopiert.

cocoaspell deutsch Wörterbuch Auch das stelle kein Problem dar (lediglich sudo wird benötigt). Der Ordner zeigt auch eine Menge an Dateien, unterscheidet sich allerdings leicht vom Inhalt des englischen Ordners, der dort schon lag.

Mein erster Versuch eine Prüfung durchzuführen
aspell --lang=de_DE -c artikel.txt
endete dann auch mit einer Fehlermeldung.

Das deutsche Wörterbuch wurde nicht gefunden! Daraufhin schaute ich mir die Config-Datei mit dem Befehl:

aspell dump config

an. Tatsächlich stand dort ein anderer Pfad drin. Die config liegt im etc-Ordner. Also habe ich die Datei geöffnet und den korrekten Pfad zum dictionary eingetragen. Diesmal kam eine andere Fehlermeldung:

The file "/Library/Application Support/cocoAspell/aspell6-de-20030222-1/de-common.rws" can not be opened for reading.

Das glaube ich gerne, denn diese Datei ist auch gar nicht vorhanden. Was allerdings vorhanden war ist eine Datei README und wenn sie schon so heisst, sollte man sie auch lesen. Dort habe ich dann erfahren dass die vorliegenden cwl-Dateien Archive sind und mit dem Befehl preunzip entpackt werden müssen.

preunzip de-common.cwl
preunzip de_DE-only.cwl

Damit liegen sie jetzt als wl-Dateien da, aber immer noch nicht als rws. Hierfür muss man jetzt aspell selbst verwenden:

aspell --lang=de create master de_DE-only.rws < de_DE-only.wl
aspell --lang=de create master de-common.rws < de-common.wl

Dies erstellt die rws-Dateien und auch die Konfiguration sieht jetzt sauber aus.

Hier noch mal zusammengefasst was nötig ist um cocoaspell deutsch laufen zu lassen.

Schnellanleitung cocoaspell deutsch einstellen

  1. Installation cocoaspell
  2. Download deutsches Wörterbuch
  3. Entpacken des Wörterbuches
  4. Kopieren des Wörterbuchordners in /Library/Application Support/cocoAspell
  5. Preunzip der beiden cwl-Dateien
  6. Aufruf aspell mit create-master für die beiden wl-Dateien

README sollte gelesen werden!

Hoffe, ich habe anderen README-NICHT-LESERN mit diesem Artikel geholfen und viel Erfolg bei der Installation.

Unicode-Zeichen HTML

Verwendung Unicode-Zeichen HTML und CSSIm Beitrag zu Musiknotation und Styling habe ich die Verwendung von Unicode-Zeichen für kleinere Aufgaben vorgeschlagen.

Hier eine Auflistung unterschiedlicher Methoden, wie dies praktisch umzusetzen ist und wie man damit auch Aufwand reduzieren kann.

Falls Sie diese Methoden auch für eBooks verwenden wollen, testen Sie bitte ob das Format und der eReader das entsprechende CSS-Feature auch unterstützt. Browser jedenfalls unterstützen die hier gezeigten Methoden (so lange es sich nicht um ganz alte Browser handelt).  Die hier verwendeten Zeichen werden auch von den Standard-Fonts unterstützt, so dass kein spezieller Font eingebunden werden muss.

Unicode-Zeichen HTML und CSS Methoden

1) Verwendung als Entity und Inhalt

Dies ist die einfachste Version. Sie geben lediglich den Code in dezimaler (&#), oder hexadezimaler (&#x) Darstellung an und das entsprechende Glyph erscheint.

<p>
 <span>Hinweise für Gitarre &#x1f3b8;</span> 
</p>

Sie benötigen kein spezielles Styling.

2) VERWENDUNG mit Pseudo-Element und Content-Attribut

HTML:

<p>
 <span class="bpm">= 120</span> <br /> 
</p>

CSS:

.bpm:before {
 content: '\2669';
}

Hier wird das Zeichen (escaped) mit seinem Unicode-Hex-Wert als content-Attribut angegeben. Das Pseudoelement before sorgt dafür, dass das Zeichen vor dem eigentlichen Inhalt (=120) angezeigt wird.

3) VERWENDUNG MIT PSEUDO-ELEMENT UND CONTENT-ATTRIBUT

Sie können die Zeichen auch als Listen-Bullets verwenden.

HTML:

<ul class="guitar">
 <li>Eintrag 1</li>
 <li>Eintrag 2</li>
</ul>

CSS:

ul.guitar { 
 list-style: none;
} 
ul.guitar li:before {
 display: inline-block;
 width: 1.6em; 
 content: '\1f3b8';
 font-size: 70%;
}

Auch hier wird das Pseudo-Element verwendet und dafür in der Liste der list-style auf none gesetzt.

4) VERWENDUNG MIT DATEN-ATTRIBUT

Eine elegante Lösung, da sie Wiederverwendung ermöglicht, ist der Einsatz von data-Attributen. Hiermit können einer CSS-Klasse Werte übergeben werden und somit Werte dynamisch gesetzt werden.

HTML:

<p>
 <span data-number="&#x2780;"> = e-Saite</span> <br /> 
 <span data-number="&#x2781;"> = h-Saite</span> <br /> 
 <span data-number="&#x2782;"> = g-Saite</span> <br /> 
 <span data-number="&#x2783;"> = D-Saite</span> <br /> 
 <span data-number="&#x2784;"> = A-Saite</span> <br /> 
 <span data-number="&#x2785;"> = E-Saite</span> <br /> 
</p>

CSS:

span[data-number]:before {
 content: attr(data-number);
}

Wiederum verwenden wir das Pseudoelement before. Diesmal sind wir jedoch nicht auf ein Zeichen beschränkt, sondern übergeben das gewünschte Zeichen an die Klasse.

Unicode-Zeichen HTML title in anchor

Sie können die Zeichen sogar im Titel-Attribut eines Links verwenden und so den Tooltip etwas aufhübschen.

<a href="#" title="&#x1f3b8; guitar">Zur Gitarrenseite</a>

Das sind die Methoden, die mir zum Thema Unicode-Zeichen HTML eingefallen sind. Hoffe, Sie dienen Ihnen als Anregung für eigene Experimente.

Bei Fragen hpv@leo.uberspace.de

eBook-Erstellung und Qualität

eBook-Erstellung und QualitätJemand, dessen Artikel voller Rechtschreibfehler sind und dessen eBooks qualitativ verbesserbar sind, schreibt über Qualität in der eBook-Erstellung?

Ja! Weil ich Fehler mache, kann ich auch über Sie reflektieren und mir Gedanken über Ursachen und Lösungsansätze machen.

Als Software-Entwickler war meine erste Erkenntnis aus der Analyse:

Ein eBook ist ein Stück Software!

Damit unterliegt es den gleichen Gesetzmäßigkeiten, denen auch andere Software in der Entwicklung unterliegt. Was bedeutet das für eBook-Erstellung und Qualität?

Wenn wir uns darauf einigen können, das die
Erstellung eines eBooks der Entwicklung einer Software gleicht, dann kennen wir einen großen Teil der Probleme und können uns in Lösungsräumen umschauen, die diese Probleme adressieren. In der Softwareentwicklung gibt es zwei Hauptprobleme:

  • Komplexität
  • Änderungsanforderungen

Die Kombination verstärkt das Problem, denn fast jede Softwareänderung führt zu einer Komplexitätszunahme.

Eine Software und damit auch ein eBook soll korrekt sein. Korrekt bedeutet hierbei nicht nur fehlerfrei, sondern auch passend im Sinne der Anforderungen/Ziele.
Die Gestaltungsgrundsätze der Softwareergonomie für neue Medien geben uns allgemeine Ziele vor:

  1. Eignung für das Kommunikationsziel – verwendete Informationen / Medien unterstützen die intendierten Kommunikationsziele.
  2. Eignung für Wahrnehmung und Verständnis – Inhalte sind so aufbereitet, dass sie gut rezipiert werden können und leicht verständlich sind.
  3. Eignung für die Exploration – Informationen sollen gut strukturiert sein, so dass die Erkundung der Informationen und das Stöbern in den Informationen leicht ist.
  4. Eignung für die Benutzungsmotivation – Das Programm soll zur Benutzung motivieren und eine hohe Bindung des Nutzers erreichen.

Die Umsetzung dieser Vorgaben wird durch Besonderheiten im Bereich eBooks erschwert.

  • mehrere Formate: ePUB, ePUB3, mobi, kf8
  • unterschiedliche eReader: ADE-basiert, Kindle, iPad

Mancher fragt sich jetzt vielleicht, warum ich eBooks als komplex betrachte und wo sollen die Änderungsanforderungen herkommen und wieso sollte Korrektheit ein Problem sein – Validator drüber, fertig!

Lassen Sie mich ein einfaches Beispiel geben. Sie haben zwei unterschiedliche Worte in Ihren Texten, die Sie hervorheben möchten. Sie entscheiden sich für eine strukturelle Lösung und setzen die Worte in em-Tags. Während der Arbeit erkennen Sie, dass Sie eines der Worte lieber fett gedruckt haben wollen. Was nun? Versehen Sie das em-Tag in Ihrem Stylesheet nun mit Fettschrift? Dann ist auch das zweite Wort fett. Wahrscheinlich bleibt Ihnen nichts anderes übrig, als alle Vorkommen von Wort1 zu suchen und dort explizit zu ändern. In der Programmierung würde man dieses Problem mit fester Kopplung beschreiben. Je mehr und je enger Dinge miteinander verbunden sind um so komplexer ist ein System.

Ein Validator hätte Ihnen hier nichts gebracht. Ihr Text ist zwar valide, aber ist er korrekt, gemessen an Ihrer eigenen Zielsetzung? Wenn Sie den Aufwand der Bereinigung scheuen, oder Angst haben die Änderung vorzunehmen, geben Sie sich mit schlechterer Qualität zufrieden.

Dies ist nur ein kleines Beispiel, aber hier kommt die These der “broken windows” ins Spiel. Nach ihr beginnt der Verfall von Qualität mit solchen Kleinigkeiten, die nur lange genug unbeachtet bleiben müssen, um zum Verfall zu führen. Dies ist ein bekanntes Softwarephänomen und führt, je älter eine Software ist, zu immensen Kostensteigerungen, bis hin zur Neuprogrammierung. Es gibt in der Programmierung Prinzipien und Werkzeuge, die zu besserer Qualität führen und die Arbeit zudem erleichtern.

eBook-Erstellung und Qualität aus Sicht eines Softwareentwicklers

CCD (Clean Code Developer) hat diese Prinzipien, die Praktiken und Werkzeuge in ein Wertesystem eingebunden und dieses in Stufen (Grade) unterteilt. Vieles des dort gesagten ist (aus meiner Sicht) auf die Erstellung von eBooks übertragbar.
“Make it a habit!”. Will man etwas verändern so ist es nicht mit einer einmaligen Aktion getan, sondern es muss eine Gewohnheit werden. Diesen Ansatz verfolgt auch CCD und gibt uns hier die Pfadfinderregel an die Hand:

Hinterlasse einen Ort immer in einem besseren Zustand als du ihn vorgefunden hast!“.

Damit sind unsere Dokumente gemeint, seien es nun Textdateien, Stylesheets oder XML-Files. Wann immer man eine Datei öffnet und liest, sollte Sie danach besser sein, als vorher. Dies kann im einfachsten Fall die Einrückung unserer Tags im HTML sein, oder ein komplexes “Refactoring” unseres Buches sein. Eine Überarbeitung (refactoring) ist nur dann möglich, wenn wir angst frei sind. Wenn wir Angst haben mit der Änderung etwas zu zerstören, in das wir schon so viel Aufwand und Herzblut gesteckt haben, werden wir es nicht angehen. Deshalb ist eine der ersten Forderungen die Verwendung eines Versionskontrollsystems. Ob es nun git oder SVN ist, oder im schlechtesten Fall, versionierte Ordner auf Ihrer Backup Platte. Mit einem Versionskontrollsystem geht nichts verloren und wir können auf alte Versionen zurückgreifen. CCD sagt hierzu:

Damit ist ein Versionskontrollsystem die allerbeste Grundlage für alles Lernen. Denn Lernen bedeutet Fehler machen. Mit einem Versionskontrollsystem als Sicherheitsnetz können wir uns alle Fehler erlauben.

Dies ist wichtig, denn Lernen ist ein weiterer Erfolgsfaktor für die Steigerung der Qualität. Lernen und Reflexion. Fehler erkennen und sich selbst fortbilden um immer bessere Lösungen für die Vermeidung/Bereinigung von Fehlern zu bekommen.

Nehmen wir unser Beispiel von oben. Wurde hier etwas falsch gemacht bzw. hätte das Problem umgangen werden können? Wir haben die Struktur unseres Dokumentes hart an den Inhalt gekoppelt. Hätten wir hier CSS-Klassen für Wort1 und für Wort2 erstellt, so wäre diese Änderung mit minimalem Aufwand realisierbar gewesen. Halte Inhalt, Struktur und Format getrennt. Auch wenn em aus semantischer Sicht eine gute Wahl ist, so wäre hier ein span mit Klasse, oder auch ein em mit expliziter Klasse wahrscheinlich besser gewesen.

Wir hätten es merken können, als wir das zweite Wort in ein em-Tag gesetzt haben. In der Programmierung spricht man davon das “Code schlecht riecht“. Das em ist nicht falsch, hat aber ein Gerüchlein. Wir müssen für diese Gerüche aufmerksam werden und dann die Pfadfinderregel anwenden. Im Bereich des Styling können wir weitere Prinzipien zur Anwendung bringen.

DRY (don’t repeat youself). SRP (Single Responsibility Principle). Wenn wir in mehreren Klassen die gleiche Anweisung finden, dann riecht das und wenn eine Klasse zu viele Dinge auf einmal macht, dann besteht die Gefahr, dass wir DRY verletzen müssen um Teile dieser Anweisungen auch an anderer Stelle verwenden zu können.

Weitere Prinzipien sind KISS (keep it simple, stupid) “Gerade in technischen Details steckt die Versuchung, eine komplizierte Lösung anzustreben. Das Bekannte, naheliegende ist manchmal zu ‘langweilig’ – und schon hat sich eine komplizierte Lösung eingeschlichen. Wenn die einfache Lösung auch funktioniert, sollte ihr Vorrang gewährt werden.” und YAGNI (you ain’t gonna need it) “Nach der YAGNI-Regel wird nur das unzweifelhaft und unmittelbar Nutzbringende implementiert. Alles andere… nun, das kommt später. Insofern geht YAGNI Hand in Hand mit der Regel ‘Entscheide so spät wie möglich’“.

Warum einen font-style: normal setzen, wenn das gar nicht nötig ist. Dies gilt auch für die Struktur. Einfach halten und nur das implementieren, das gerade wirklich nötig ist. Wenn wir refactoring und Versionskontrolle akzeptiert haben, stellt eine spätere Erweiterung kein Problem dar. Eine unnötige frühe Implementierung erhöht dagegen die Komplexität.
Neben Prinzipien benötigen wir auch Verfahren und Vorgehensmodelle. In der Programmierung ist Unit-Testing ein solches Modell. Testbarer Code auf unterster Ebene führt zu loser Kopplung und zu kleinen Einheiten. Es geht zwar auch um Korrektheit bei diesen Test, aber in erster Linie ist es ein Verfahren um Abhängigkeit von vornherein zu minimieren. Wir können dies auch auf die eBook-Erstellung übertragen.

Was sind unsere Units? Wir haben Textpassagen, wir haben Strukturfragmente, Styles und Assets, wie Bilder. Diese Tests müssen in einem frühen Stadium erfolgen. So müssen wir die Anzeige eines Bildes evtl. schon testen, bevor wir das Bild überhaupt zur Verfügung haben. Wir verwenden also Platzhalter (mocks). Texte können wir mit einer Rechtschreibprüfung testen, Strukturen und Gesamtbild im Browser. Unser HTML können wir validieren.

Wenn wir wirklich gute Qualität wollen, werden wir nicht umhin kommen unterschiedlichste Versionen unseres Buches zu erstellen. Für unterschiedliche Formate und unterschiedliche Plattformen. Genau hierfür benötigen wir Unit-Tests. Wird dieses CSS-Feature im Mobi-Standard unterstützt? Wie verhält sich ADE bei Tabellen? Wir testen nicht unser Buch, sondern Komponenten, die wir in dem Buch verwenden.

In der Programmierung kennen wir dann noch den Integrationstest. Wie verhält sich das Gesamtsystem (unser Buch)? Sind alle Assets vorhanden, ist die OPF-Datei vollständig? etc. Diese Tests kommen zu einem späteren Zeitpunkt. Hier kommt dann auch die oben genannte Validierung ins Spiel. Unser workflow muss gegebenenfalls angepasst werden. Wenn meine Rechtschreibprüfung nicht mit HTML-Tags funktioniert, dann muss ich erst den Text erstellen, dann die Prüfung und dann erst das Markup.

Für unsere Prinzipien und Verfahren benötigen wir Werkzeuge. Wie schon genannt, benötigen wir ein Versionskontrollsystem, eine Rechtschreibprüfung. Für komplexeres Refactoring benötigen wir einen guten Editor, oder müssen Unix-Befehle beherrschen, die solche komplexen Textüberarbeitungen erlauben. Eventuell benötigen wir ein Bildbearbeitungsprogramm. All dies will beherrscht, also erlernt werden. Genau diese Anforderungen führen dazu, dass ich im Web zwei Trends erkennen kann.

  • - (d)DIY (don’t do it yourself). Man soll seine Texte an Profis geben und bezahlen
  • - Eier-legende Wollmichsau. Man erhofft sich von Programmen wie Calibre, Sigil, etc. dass Sie uns das alles abnehmen.

Beidem möchte ich widersprechen. Ich halte Selfpublishing für eine gute Sache. Nur so bekommen wir endlich die vielen Geschichten, die Menschen zu erzählen haben, oder die Kenntnisse Tausender auf den Markt. Kein Programm kann den hier geforderten Qualitätsansprüchen gerecht werden. Hierzu benötigt es Menschen und nicht Software. Ob Sie ein PDF konvertieren, oder ein eBook von Grund auf erstellen, Programme können nur Werkzeuge für Teilaufgaben sein. Je öfter wir unser Buch überarbeiten, um so nötiger ist ein gewisser Automatisierungsgrad. Ein Buch erneut zu zippen, oder weitere Dateien zum Manifest hinzufügen, darf uns von Aufwand her nicht davon abhalten refactoring vorzunehmen.

Angesichts der Tatsache, dass Code öfters gelesen, als geschrieben wird, noch ein Wort zu Dokumentation und Kommentaren. Für mich ist die Dokumentation, die nicht benötigt wird, die beste. Man erreicht dies durch sprechende Namen und Namenskonventionen. Wenn wir unser Div mit einer Klasse Kapitel versehen, müssen wir nicht dokumentieren, dass es sich strukturell um ein Kapitel handelt.

Wenn wir saubere Dateinamenskonventionen haben, erleichtert dies die Automation und wir müssen nicht dokumentieren, was sich in dieser Datei befindet. Eine Datei sollte deshalb auch nie mehr als ein Kapitel beinhalten. Die Einhaltung von Namenskonventionen ist eine Hauptaufgabe unseres Pfadfinderprinzips.

Wie CCD bin ich der Meinung, dass man für Qualität in diesem Bereich keine Checkliste vorlegen kann. Es geht in erster Linie um Bewusstsein und ein entsprechendes Wertesystem. Man muss sich angewöhnen gute Qualität zu liefern (make it a habit).
Dennoch möchte ich hier noch mal die wichtigsten Punkte listen (Stufen möchte ich nicht einführen).

  • - Bewusstsein
  • - Versionskontrollsystem
  • - Pfadfinderregel
  • - Trennung Inhalt – Struktur -Format
  • - Rechtschreibprüfung
  • - kleine Dateien (max 1 Kapitel in einer Datei)
  • - Namenskonventionen
  • - KISS
  • - DRY
  • - Unit-Tests
  • - SRP
  • - YAGNI
  • - Automatisierung

Noch etwas Grundsätzliches. Es ärgert mich, dass so viele schlecht gemachte Bücher auf dem Markt sind. Einige davon sind sicherlich der Suche nach dem schnellen Geld geschuldet (Bücher mit geschätzten 42 Seiten, 36 Kapiteln und einem Inhaltsverzeichnis das schon 6 Seiten einnimmt). Den anderen sieht man jedoch an, dass hier der kleinste gemeinsame Nenner gesucht wurde. Wer Bücher für schwache eReader oder schwache Formate erstellt, muss Abstriche in der Umsetzung machen, aber diese Bücher muss man dann nicht identisch als ePUB auf iBooks veröffentlichen. Als Autoren wünschen wir uns viele Gestaltungsmöglichkeiten, wie z.Bsp. in ePUB3. Solange unsere ePUB3-Bücher aber aussehen, wie unsere MOBI-Bücher, können wir die Großen nicht zwingen Ihre Standards anzupassen. Es liegt auch an uns.

Erstellen Sie mehrere Versionen. Zeigen Sie wie ein gutes Buch aussehen kann.

Wenn die Leser dann nur noch die “guten Bücher” kaufen, wird jeder versuchen, gute Bücher auch für seinen eReader und sein Format zu ermöglichen.

Dies ist meine Sicht auf die Dinge und sicher nicht der Weisheit letzter Schluß. Es würde mich freuen, wenn andere Ihre Gedanken hierzu einbringen würden und diese z.Bsp. in Kommentaren öffentlich machen. Zum Thema Qualität im Bereich self-publishing habe ich im Web leider nicht viel gefunden.

Instrumentenspezifisches Styling

Musik-Styling #2

Oftmal benötigt man zur Vermittlung von musikalischen Informationen schematische Darstellungen, die instrumentenspezifisch sind. So findet man bei Materialien für die Gitarre oftmals ein schematisches Griffbrett, oder für das Klavier eine Darstellung der Klaviertasten. Deshalb hier ein kleiner Beitrag zu Instrumentenspezifisches Styling.

Instrumentenspezifisches Styling für Gitarre

Instrumentenspezifisches Styling Gitarre

Hier habe ich eine Tabelle verwendet um ein Griffbrett zu erstellen. Die einzige Schwierigkeit bei diesem Instrumentenspezifisches Styling liegt darin, dass man auf die Linien (Zellenränder) schreiben muss. Dies geht durch die Verwendung von Span-Elementen und mittels relativer Positionierung. Zuerst das Griffbrett:

table.fretboard tr td {
 border: 1px solid #bbb; 
 margin: 0; 
 width: 3.2em; 
 height: 1.4em; 
 text-align: center; 
 vertical-align: middle;
}

Dort wo Noten, oder Fingersätze dargestellt werden sollen, wird ein Span in die Zelle geschrieben.

span.note, span.note2 { 
 display: inline-block;
 position: relative; 
 top: -0.75em; 
 border: 1px solid #117;;
 border-radius: 50%; 
 height: 1.2em;
 color: #fff; 
 background: #228; 
 vertical-align: middle;
 text-align: center; 
}
span.note { 
 width: 1.2em; 
}
span.note2 { 
 width: 2em; 
}
<td><span class="note">4</span></td>

Die Saiten und Bundbezeichnungen, sind zusätzliche Spalten bzw. Zeilen, die dann über Pseudoklasse separat gestylt werden.

table.fretboard tr:nth-child(6) td, table.fretboard tr:nth-child(7) td { 
 border: 1px solid #fff; 
}

Instrumentenspezifisches Styling für Klavier

Instrumentenspezifisches Styling für Klavier

für die Erstellung einer Klaviertastatur findet man einige Vorschläge im Web. Die meisten verwenden hierfür eine unordered List. Innerhalb eines Listeintrages kommen dann entweder zwei Span (z.Bsp. C und CIS), oder ein Span (Bsp. E) zum Zuge. Diese Spans werden mit Klassen für schwarze und weisse Tasten versehen.

.weiss {
 width: 100%;
 height: 100%;
 float: left;
 box-shadow: 0 1px 1px rgba(0, 0, 0, .5);
 position: relative;
 z-index: 1;
 line-height: 220px; 
} 
.schwarz {
 height: 70px;
 position: absolute;
 top: 0px;
 right: -40%;
 width: 70%;
 background: #222; 
 border-width: 1px 3px 5px;
 border-style: solid;
 border-color: #666 #222 #111 #555;
 box-shadow: inset 0px -1px 2px rgba(255, 255, 255, 0.4), 0 2px 3px rgba(0, 0, 0, 0.4); 
 z-index: 2; 
 color: #fff; 
 line-height: 120px;
}

Durch unterschiedliche Randstärken und Box-Shadow kann man etwas Plastizität in die Darstellung bringen.

<ul class="klavier">
 <li class="taste"><span class="weiss">C</span><span class="schwarz">CIS</span></li>

Um die Beschriftung korrekt zu setzen habe die line-height-Eigenschaft erhöht, so dass die Beschriftung nach unten geschoben wird.

Instrumentenspezifisches Styling für Flöte

Instrumentenspezifisches Styling für Flöte

Hier habe ich einen etwas anderen Ansatz gewählt. Ich verwende ein DIV, dessen Hintergrund-Bild der Umriss der Flöte ist. Die Löcher sind in diesem Bild nicht vorhanden.

In das Div positioniere ich eine unordered List mit sieben LI-Elementen. Ob ein Loch zu oder offen ist steuere ich über Klassen, die im content-Attribut entweder einen schwarzen, oder einen weissen Kreis verwenden.

Das Loch an der Unterseite verwendet zusätzlich noch das Unicode-Zeichen für halbgefüllten Kreis. Um den Status dieses Loches zu setzen, verwende ich ein data-Attribut ohne Inhalt. So können die unterschiedlichen Zustände über Klassen (zu, offen) und data-Attribute (z.Bsp.: data-halb) abgebildet werden.

 

div.floete {
 background-image: url("blockfloete.png"); 
 background-repeat: no-repeat;
 background-size: 40px 320px; 
 height: 320px; 
 margin: 12px;
} 
ul.loecher {
 position: relative;
 top: 130px;
 left: 14px; 
 padding: 0;
} 
ul.loecher li {
 list-style: none;
 padding: 0;
 margin-top: -4px;
} 
ul.loecher li:last-child {
 margin-top: 6px; 
}
span.zu, span.offen {
 font-size: 14pt;
} 
span.zu:before {
 content: '\25CF';
}
span.offen:before {
 content: '\25CB';
}
span[data-halb]:after {
 content: '\25d2'; 
 position: relative; 
 width: 0;
 left: -30px; 
 top: -2px; 
 font-size: 12px;
}

Das HTML ist dadurch simpel:

<div class="floete">
 <ul class="loecher">
  <li><span class="zu" data-halb></span></li>
  <li><span class="zu"></li>
  <li><span class="offen"></span></li>
  <li><span class="zu"></li>
  <li><span class="zu"></li>
  <li><span class="zu"></li>
  <li><span class="offen"></li>
 </ul>
</div>

Zugegeben, man kann dies besser machen, aber ich bin kein Web-Designer. Trotzdem zeigt es, denke ich, wie man mit geringen Mitteln auch mit HTML und CSS zu ansprechenden Ergebnissen kommen kann und der Kreativität zur Vermittlung von musikalischen Inhalten keine Grenzen gesetzt sind.

Hoffe, ich konnte die eine oder andere Anregung für Instrumentenspezifisches Styling geben.