Für so manchen könnte das auch den Weg von Microsoft Word (DOC/DOCX) nach EPUB eröffnen, wobei ich mal stark anzweifle, dass Word valides XHTML rausschreiben wird. Webseiten könnten nach dem Speichern durch den Browser zu EPUBs aufbereitet werden. Für Mozilla Firefox gibt es ein Plugin namens "GrabMyBooks", mit dem EPUBs frisch geschrieben werden können, aber in erster Linie Webseiten via Kontextmenü zu einem EPUB-Buch zusammengestellt werden können. Allein bei meinen eigenen Tests hat das leider schon nicht bei relativ simplen Webseiten komplett richtig funktioniert, auch ist das nicht besonders automatisierbar, deshalb in Zukunft vielleicht bald eine eigene Lösung.

Bis zur Stunde wird die Konfigurations-XML eingelesen, welche ihrerseits mehrere XHTMLs und ein Ausgabe-Verzeichnis angibt. Für jede XHTML-Datei wird eine Validierung gegen XHTML 1.0 Strict durchgeführt (Schema liegt lokal vor), die man aber auch überspringen kann, da sie ziemlich viel Zeit in Anspruch nimmt. Dabei ist höchst beachtlich, dass jeweils der W3C-Validator (valid), der Validome-Validator (kein "px" bei height- und width-Angaben, "content-style-type" für lokale style-Angaben erforderlich), eine lokale Validierung mit xmlstarlet (keine HTML-Entities) und die lokale Validierung mit html2epub, d.h. Java's javax.xml.validation (kein "px" bei height- und width-Angaben) zu unterschiedlichen Ergebnissen führte. Letztendlich soll das Tool aber so streng sein, damit möglichst auch ein gültiges EPUB2 am Ende dabei herauskommt. Die veränderten XHTMLs sollen nach der Transformation nochmal validiert werden, ebenso ODF und NCX gegen lokal vorliegende Schemen. Eine ganzheitliche Prüfung der fertigen EPUB-Datei wird wohl nicht stattfinden können, da manche Trivialitäten und manche Spezialitäten auch gut übergangen werden können, indem sich dann z.B. der BookRix-EPUB-Validator beim Upload darum kümmern darf ;-)

Mittlerweile wird im Ausgabe-Ordner die mimetype-Datei, der META-INF-Ordner samt der dazugehörigen container.xml angelegt, ein Teil der OPF-Datei geschrieben (Metadaten) sowie die XHTMLs mit neuem Namen dorthin kopiert. In den darauffolgenden Schritten sollen die XHTMLs erstens die Dateiliste für die ODF- und NCX-Datei zusammenstellen, Verweise auf den EPUB-Ordner umstellen als auch womöglich referenzierte Dateien (Bilder) in selbigen kopieren. Anschließend können die Dateien mithilfe von Zip zu einem EPUB2 zusammengepackt werden.

Nun habe ich mit der Erzeugung der Dateiliste für die ODF-Datei begonnen, wo in den XHTML-Eingabedateien nach Verlinkungen auf lokale andere XHTMLs gesucht werden soll, um diese ggf. ins EPUB zu integrieren oder mindestens eine Fehlermeldung auszugeben, dass diese referenzierte Datei in die Liste der Eingabe-Dateien aufgenommen werden muss. Außerdem müssen lokal vorliegende Bilder identifiziert und ins EPUB-Ausgabeverzeichnis kopiert werden. Dabei schien es zunächst so, als ob das Einlesen der XHTML endlos dauern würde, wenn ein DOCTYPE angegeben ist, letztendlich liegt das aber daran, dass wohl das im DOCTYPE angegebene DTD heruntergeladen und vielleicht sogar für eine Validierung herangezogen wird, was nun zukünftig über entspr. Optionen in der Konfigurationsdatei ein- oder ausgestellt werden können soll. Glücklicherweise ist die vermeintliche Endlosschleife damit kein grundsätzlich unlösbares Problem, sodass die Entwicklung nun weiter fortschreiten kann.

Klasse, klingt gut. Ich verstehe zwar den Inhalt deiner Kurzberichte, würde aber selbst nicht auf die Idee kommen, munter ein paar Programme zwecks EPUB2 Erstellung zu programmieren.

Hut ab und weiterhin viel Erfolg.

Naja, erst mal abwarten, bis die erste Version steht und dann feststellen, was alles noch nicht funktioniert ;-) Jedenfalls vielen Dank - das Tool könnte vielfältige Anwendungsmöglichkeiten erschließen, wie z.B. Wikipedia-Artikel als EPUB auf E-Readern herumtragen zu können (falls die Wikipedia-Software keinen EPUB-Export hat), aber auch andere Webseiten könnten so mobil auch ohne Internet-Verbindung mitgeführt werden. Hinzu kommt, dass viele Programme XHTML exportieren können, und es können zukünftig noch Tools entwickelt werden, welche solche XHTMLs erzeugen, wie sie von html2epub gut entgegengenommen werden können, womit ein geschriebener Text etwa von vornherein gleich als Webseite und als EPUB zur Verfügung stünde. Zusätzlich bietet sich stets die Möglichkeit der automatischen Verarbeitung, da man in XHTML sehr gut mittels XSLT eingreifen kann.

Es sind jetzt einige Optionen des XML-Readers durch die Konfigurationsdatei von außen ansteuerbar.

html2epub ermittelt nun die Pfade von lokal referenzierten Bilddateien im XHTML. Absolute Pfadangaben können dabei bisher noch nicht berücksichtigt werden, da Java keine Möglichkeit bietet, betriebssystemunabhängig zu prüfen, ob eine Pfadangabe absolut oder relativ ist.

Für die Erzeugung der OPF werden nun aus allen als Eingabe-Dateien konfigurierten XHTMLs alle relativen Links innerhalb derselben auf lokale, andere XHTMLs sowie lokal und relativ referenzierte Bilder ermittelt. Mit dieser Information kann geprüft werden, ob alle benötigten XHTMLs Teil des EPUBs werden würden (sprich: ob auch alle referenzierten XHTMLs in der Konfiguration als Eingabe-Dateien eingetragen wurden). Da im OPF für die Bilder ein Mimetype angegeben werden muss und in Java keine Möglichkeit besteht, einen Dateitypen sicher zu ermitteln (Dateinamenerweiterungen sind dabei wenig aussagekräftig), werden wohl auch alle Bilder, die im resultierenden EPUB verwendet werden sollen, in der Konfiguration zu hinterlegen sein (mitsamt passendem Mimetype). Wenn der Benutzer hier falsche Angaben vornimmt, wird es entgegen des ursprünglichen Ziels für html2epub möglich sein, ungültige EPUBs zu erzeugen. Vielleicht sollte zukünftig ein Prüf-Versuch anhand des Dateiinhalts als auch eine Berücksichtigung der Dateiendung stattfinden, um wenigstens annäherungsweise auch diese Komponente so weit wie möglich automatisieren zu können. Andererseits: wenn schon alle XHTMLs explizit angegeben werden müssen, könnte dies auch auf andere Dateitypen wie Bilder ausgeweitet werden. Später könnte eine grafische Oberfläche die Bedienung von html2epub derart erleichtern, dass Bilder zu der Konfiguration hinzugefügt werden können und der Nutzer in einem Drop-Down eigenverantwortlich den konkreten Bild-Dateitypen hinterlegen muss.

Die letzten Feiertage haben große Fortschritte ermöglicht, welche hier nur sehr zusammengefasst wiedergegeben werden sollen: Die XHTML-Dateien werden nicht mehr länger komplett kopiert, sondern gleichzeitig in Form von einzelnen Textbestandteilen aus der Quelldatei gelesen und in die Zieldatei geschrieben. Damit können Links natürlich besonders einfach umgesetzt werden. Jetzt fehlt eigentlich nur noch die Zip-Komponente, worauf man aber verzichten kann, wenn man die Dateien im Ausgabe-Ordner von Hand oder per Script zum EPUB zusammensetzt. Somit steht nun eine erste Version zur Verfügung, die noch viele Features vermissen lässt, aber immerhin zur EPUB-Erzeugung bereits verwendet werden kann:

http://github.com/skreutzer/text_processing/tree/master/html2epub/html2epub

Damit wird dieser Thread hier nicht mehr den Entwicklungsfortschritt dokumentieren, welchen man ja nun im öffentlichen Repository mitverfolgen kann, sondern die Gelegenheit für BookRixler bieten, Wünsche, Anregungen, Fragen und Kritik zu html2epub zu äußern - insbesondere auch auf die Frage, wie man das Tool auf dem eigenen Rechner einrichtet und benutzt, sofern hier Hilfe erwünscht wäre.

Jetzt ist also auch die Zip-Komponente vorhanden, sodass mit html2epub EPUB2s erzeugt werden können, sofern man eine oder mehrere gültige XHTML-Dateien vorliegen hat.

CSS in <head> bleibt nun erhalten, wobei Verweise auf lokale CSS-Dateien sowie die Referenzierung von Schriftart-Dateien per @font-face bisher noch nicht unterstützt werden.