E-Books für Wikisource mit KF8-Support

Ab sofort biete ich die E-Books, die ich aus den Beständen von Wikisource erstelle, auch im neuen Kindle-Format 8 an, kurz KF8 genannt. Das KF8 ist eine Weiterentwicklung des ursprünglichen Mobipocket-Formats und bietet eiune wesentlich bessere Unterstützung der aktuellen Technologien. Amazon beschreibt die Vorteile folgendermassen auf der oben verlinkten Webseite:

Kindle Format 8 is Amazon’s next generation file format offering a wide range of new features and enhancements – including HTML5 and CSS3 support that publishers can use to create all types of books. KF8 adds over 150 new formatting capabilities, including drop caps, numbered lists, fixed layouts, nested tables, callouts, sidebars and Scalable Vector Graphics

Hinzu kommt, dass Bilder nicht mehr so arg kleingerechnet und in schwarz-weiß umgerechnet werden, da mit diesem Format auch der Kindle Fire umgehen kann, der eine größere Auflösung bietet und auf Grund des verwendeten LCD-Bildschirms auch farbige Bilder anzeigen kann. Wenn also das Gerät irgendwann auch in Europa angeboten wird, profitieren Besitzer dieses Gerätes sofort von dem neuen Format. Außerdem ist die Liste der unterstützten HTML-Tags und CSS-Eigenschaften wesentlich größer als noch beim alten Kindle-Format. Und da der seit ein paar Tagen in Deutschland erhältliche Kindle Touch dieses neue Format unterstützt, habe ich mich entschlossen, die E-Books auch in diesem Format anzubieten.

Amazon zieht damit gleich zur aktuellen EPUB-Version 3, die einen ähnlichen Funktionsumfang seit Anfang 2011 definiert.

Den Unterschied in der wesentlich besseren Darstellung auf dem Kindle Touch mit KF8 im Gegensatz zum Kindle 4 kann man den beiden Screenshots entnehmen.

Screenshot Kindle 4
Screenshot Kindle 4
Screenshot Kindle Touch
Screenshot Kindle Touch

Auch wenn die generierten Dateien im KF8 dasselbe E-Book im alten Format (KF6) enthält und damit eigentlich auch zum Kindle 4 und dessen Vorgängern kompatibel ist, biete ich weiterhin einen Download nur im alten Format an. Das hat schlicht zwei Gründe: Ersten ist ein E-Book nur im alten Format wesentlich kleiner, da eben die Bilder kleiner gerechnet werden und auch keine herausgeberspezifischen eingebetteten Fonts enthalten sind, die alleine meist 1-2 MB umfassen. Und da das Wikisource-Export-Tool seit kurzem freie gut lesbare Fonts in das EPUB einbettet und ich diese auch nicht entfernen möchte, sind halt auch im resultierenden KF8-Buch diese enthalten. Ein E-Book im KF8 Format ist u.a. deshalb schlicht doppelt so groß wie das EPUB aus dem es erzeugt wird. Für den zweiten Grund muss ich etwas weiter ausholen und meinen bisherigen Workflow kurz schildern.

Zuerst exportiere ich die Texte aus Wikisource mit dem Export-Tool für Wikisource. Das liefert mir ein EPUB-Dokument. Wenn ich einen Sammelband erstellen möchte, muss ich zusätzlich noch die einzelnen Texte als XHTML-Datei exportieren, was auch durch das Export-Tool unterstützt wird.

Danach wird das exportierte EPUB-Dokument mit Sigil weiterbearbeitet, da doch noch zuviele Artefakte darin enthalten sind, die man in einem E-Book nicht haben möchte, aber in Wikisource sinnvoll sind bzw. aus der Historie bedingt sind und oft auch mit exportiert werden. Bei einem Sammelband müssen in das Manteldokument, die oben beschriebenen XHTML-Dateien eingefügt werden. Zu den typischen Aufgaben bei der Bearbeitung gehören dabei:

  • Aufbau eines Inhaltsverzeichnis soweit noch nicht vorhanden bzw. sinnvoll. Die Darstellung von Überschriften in Wikisource erfolgt nämlich meist nicht semantisch mittels HTML-Header-Tags (h1, h2 usw.) sonder nur per Schriftauszeichnung (fett, größer etc.) und lehnt sich an das Layout der Vorlage an.
  • Entfernen überflüssiger Leerzeilen
  • Überarbeiten und Ergänzung der Metadaten
  • Tabellen, die für das Layout verwendet werden entfernt. Da lange Tabelle Probleme im Kindle machen, versuche ich diese mit anderen Mitteln darzustellen.
  • So in Wikisource kein Bild zum Text mitgegeben wird (meist das Titelblatt des Textes), dass auch für das Coverbild des E-Books verwendbar ist, erstelle ich ein neues in einem schlichten, aber hoffentlich ansprechenden Layout und binde dieses in das E-Book ein. Im folgenden ein Beispiel für einen Text der in der Gartenlaube veröffentlicht wurde:
Beispiel generisches Titlebild
Beispiel generisches Titelbild
  • Entfernen von Seitenzahlen und Einzügen die mit Leerzeichen realisiert wurden, dafür ist die Suchen-Ersetzen-Funktion von Sigil mittels Regular Expressions sehr hilfreich.
  • Ich entferne Anmerkungen und Fußnoten, die nur Druckfehler korrigieren. Die sind wichtig in Wikisource, damit nicht der nächste Korrekturleser über den gleichen Fehler stolpert und weiß, dass an dieser Stelle von der Vorlage abgewichen wurde. Für den Leser des E-Books sind diese Anmerkungen m.E. unwichtig. Sachanmerkungen belasse ich allerdings.
  • Entfernt werden weiterhin Verlinkungen im Text, die aus dem E-Book herausführen, also zu Wikipedia-Artikeln oder zu anderen Texten auf Wikisource.
  • Weiterhin füge ich in die vom Export-Tool generierte Titelseite die Textdatenbox aus Wikisource ein, um diese Informationen dem Leser auch über die Metadaten des E-Books hinaus zur Verfügung zu stellen.

Anschließend wird das mit Sigil bearbeitete EPUB in Calibre, einem E-Book-Verwaltungs- und Konvertierungs-Programm, importiert und in das Mobipocket-Format konvertiert. Und hier kommt jetzt der Unterschied im bisherigen Workflow. Das EPUB-Dokument wird nun auch noch zusätzlich mit Hilfe des Kommandozeilen kindlegen von Amazon in das neue Format konvertiert. Wenn man sich das Gehacke auf der Kommandozeile sparen will oder nicht ganz so firm ist damit, verwendet man einfach den KindlePreviewer, der eigentlich zur Vorschau von Kindle-E-Books auf verschiedenen Geräten gedacht ist, aber auch EPUB, DOC und HTML entgegennimmt und diese vorab per kindlegen in das KF8 konvertiert. Neben dem von Calibre konvertierten Dokument importiere ich in Calibre zusätzlich noch das per kindlegen erzeugte Dokument.

Warum mache ich nun aber diese zusätzlich Konvertierung und erzeuge zwei Mobi-Dateien, obwohl ja die von kindlgen erzeugte auch das E-Book im alten Format enthält? Schlicht, weil die Konvertierung von Calibre wesentlich besser und näher am Ausgangs-EPUB ist, trotz der limitierten Fähigkeiten des älteren Formats. Kindlegen erzeugt zwar sehr schöne und gutaussehende E-Books im KF8 aber eben nicht im älteren Format. So werden z.B. Gedichte die in Wikisource gesetzt wurden nicht korrekt formatiert. Deshalb einmal die Version von Calibre erzeugt für Kindle 4 und dessen Vorgänger und dann für Kindle Touch und Fire die Version mit KIndlegen erzeugte Version.

Damit Calibre die beiden Versionen für den Kindle auseinander halten kann, die normalerweise beide die Dateiendung mobi tragen würden, bekommen die mit Kindlegen erzeugten von mir die Dateiendung prc verpasst, welche äquivalent zur Dateiendung mobi ist und von den Readern problemlos als E-Book erkannt werden.

AntiCommonist 0.5.0

Und heute gibt es seit langer Zeit auch mal wieder eine neue Version des Anticommonisten.

Änderungen:

  • Es gibt die neue Option -e die nur wirksam wird, wenn man Dateien aus einer Kategorie herunterlädt. Mit dieser Option können bestimmte Dateitypen vom Download ausgeschlossen werden. Dies ist nützlich, wenn man z.B. nur die Bilder aber keine PDFs in der Kategorie haben will.

Beschreibung dieser Option:

 -e,--exludefiletypes    list of file types, which will
                                          not downloaded from a category,
                                          only available if option c is used,
                                          commasepareted list

Download:

[download id=“5187″ format=“1″]

E-Books für Wikisource (3)

Gestern hatte ich noch über das Tool der fr.wikisource berichtet, das ebenfalls den Export ins EPUB-Format übernehmen kann und heute haben die Kollegen das Teil freundlicherweise für alle Wikisources auf dem Toolserver installiert: Export Tool of Wikisource Books. Und ich bin ehrlich gesagt sehr beeindruckt. Das Tool spart im Gegensatz zu dotEPUB einiges an Arbeit bei der Nachbearbeitung, da erstens alle Bilder mit übernommen werden (auch wenn offenbar nur die Thumbs die im Text eingebunden sind) und zweitens die Formatierung wesentlich besser übernommen wird. Das restliche bekommt man dann hin bzw. musste man auch mit dotEPUB machen und die Elemente, die noch im EPUB drin sind, die aber nicht reinsollen kann man pauschal per CSS-Class direkt in Wikisource rausnehmen.

Fazit: Tolle Arbeit, die ein riesen Fortschritt für Wikisource darstellt und sicherlich auch bald bei jedem Text verlinkt werden kann. Danke dafür an die französischen Wikisourcler

Achja, anstelle von dotEPUB werde ich wohl ab sofort dieses Export-Tool verwenden. An einer Nachbearbeitung der E-Books kommt man in vielen Fällen wohl aber trotzdem nicht vorbei, damit es wirklich ein gutes Ergebnis wird. Aber mal schauen, ob sich in Zukunft durch eine sorgfältige und saubere Vorbereitung der Texte in Wikisource nicht bei vielen Texten eine mühsame Nachbearbeitung erübrigt und die Texte direkt aus Wikisource heraus exportiert werden können und ein schönes Ergebnis ergeben.

UPDATE:  Ich habe in Wikisource die Textdatenbox mittlerweile so erweitert, dass sie nicht mehr im EPUB selbst erscheint, aber die dort enthaltenen wichtigsten Informationen in die Metadaten des EPUBs übernommen werden und das Export-Tool eine Titelseite und eine Coverpage mit dem in der Textdatenbox enthaltenen Bild erstellen kann.

E-Books für Wikisource (2)

Im vorigen Beitrag hat Tpt den Hinweis hinterlassen, dass das französische Wikisource an einer (halb?)automatischen Lösung für den Export von Wikisource-Büchern arbeitet. Leider kann ich kein französisch, so dass ich erstmal nicht so richtig durchblicke. Vll. hat ja jemand Lust sich das anzuschauen und zu prüfen, ob das auch für de.ws was wäre, was natürlich einiges an Arbeit sparen würde. Hier der Link zu dem Tool: http://genewiki.legtux.org/wikisource-site/wsexport/www/index.php/wsexport/.

Trotzdem aber noch eine recht lose Sammlung von Dingen die mir beim Erstellen der E-Books aufgefallen sind. Spezifische Dinge die mir auf dem Kindle oder bei einem anderen Format als EPUB  aufgefallen sind, markiere ich entsprechend :

  • Sind zuviele Bilder auf einer Seite weigert sich edotPUB diese einzubinden. Hier heisst es dann also diese wieder manuelle einzufügen. Eventuell gibt es ja noch ein besseres Browser-Plugin, was diese Einschränkung nicht hat.
  • Bewährt hat sich in solchen Fällen das Herunterladen der Bilder, falls diese in eine eigene Kategorie einsortiert sind, per AntiCommonist.
  • Zuviel typografischer Schnickschnack und Layoutnachbau per HTML und CSS in Wikisource erschwert die Erstellung des E-Books enorm. Bspw. ist die Paginierung wie auf dieser Seite sehr hinderlich. Die Standardpaginierung wie auch sonst verwendet lässt sich da wesentlich besser verwenden.
  • Da die Klassen und IDs an den HTML-Elementen fast komplett aus Wikisource übernommen wird, hab ich mir eine kleine zusätzliche CSS-Datei für die E-Books angelegt, die einen großen Teil der gewünschten Formatierung wiederherstellt, was enorm Arbeit spart. Download: [download id=“30″]
  • KINDLE: Rechts- bzw- linksbündige Bilder mit umfliessenden Text werden zwar links bzw. rechts angezeigt, der Text fliesst aber nicht um das Bild herum. Ergo kann man solche Bildanordnungen wohl komplett herausnehmen.
  • KINDLE: Lange Listen und Tabellen, die sich über mehrere Bildschirmseiten erstrecken, z.B. die Fußnoten o. ein Literaturverzeichnis, werden nicht korrekt angezeigt, wenn man bspw. über einen Fußnotenlink direkt in die Mitte der Liste springt. Offenbar liest der Reader in diesen Fällen nicht den Anfang der Liste und weiß nicht, wie die Formatierung aussehen soll. Diese Liste müssen deshalb von Hand auf einzelne Absätze umgestellt werden und die Nummerierung ebenfalls manuell nachgetragen werden.
  • Als Titelbild bietet es sich an, einfach das Bild zu verwenden, dass eh meist in Wikisource in der Textdatenbox eingebaut wird und häufig das Titelblatt oder den Einband des Werkes zeigt.
  • MOBIPOCKET: Die Titelseite die in EPUB sichtbar ist und  z.B.  Informationen zu Spezifika der E-Book-Edition und das Titelbild enthält, geht bei Konvertierung nach MobiPocket verloren. Verwendet wird nur das Titelbild. Mal schauen was man da noch machen kann.

E-Books für Wikisource

Mrs. Finanzer hat mir zu Weihnachten einen E-Book-Reader, genauer einen Kindle, geschenkt. Und ich muss sagen, ich bin begeistert. Handlich, leicht, sehr gut lesbares Display und E-Books in Hülle und Fülle, auch tausende kostenlose, da gemeinfrei oder unter freier Lizenz stehend. Also eigentlich genug Lesestoff auf Jahre hinaus. Aber auch Wikisource hat ja einiges zu bieten, dass es noch nicht als E-Book gibt.

Und da hab ich mir gedacht, warum nicht mal schauen, wie man möglichst einfach die Inhalte von Wikisource für die diversen E-Reader bereitstellen kann. Simples PDF wäre zwar nicht so schwer, aber auf einem E-Book-Reader schwieriger lesbar, da der Reader dafür das Neu-Layouten des PDFs beherrschen sollte, was z.B. Kindle nicht kann, da ansonsten das Lesen recht schwer wird. Beim Kindle muss man z.B. bei jedem PDF erstmal rumprobieren, wann es am Besten  lesbar ist: Quer- oder Hochformat, Vergrößern oder nicht, Kontrast einstellen und was man sonst noch so machen kann. Da ist ein natives E-Book doch wesentlich einfacher zu handhaben.

Also hab ich heute mal ein bisschen rumprobiert und hab mir ein paar Tools und Programme heruntergeladen, womit das Erstellen von E-Books direkt aus Wikisource heraus recht einfach zu machen ist und wenig manuelle Nacharbeit erfordert. Im Folgenden schildere ich kurz den Workflow, den ich mir zusammengebastelt habe. Vorweg schicken möchte ich, dass ich bisher nur Texte umgewandelt habe, die sich bei Wikisource auf einer Seite befinden. Den Fall, dass ein Werk auf mehrere Unterseiten (z.B. die einzelnen Kapitel o.ä.), aufgeteilt ist, habe ich noch nicht ausprobiert, was ich aber die nächsten Tagen auch noch machen möchte. Ich werde darüber berichten, insbesondere um wieviel höher der Aufwand zum hier beschrieben Workflow ist.

  1. Das eigentliche E-Book wird bereits ganz am Anfang mit einem Chrome-Plugin, das es wohl auch für andere Browser gibt, erstellt: dotEPUB. Das sendet den Inhalt einer beliebigen Webseite zum eigenen Webservice, der dann ein fertiges E-Book im EPub-Format zum Download anbietet. Das speichert man einfach auf seiner lokalen Platte. Offenbar analysiert der Webservice die Struktur der Seite und verwirft alle Elemente, die nicht zum eigentlichen Inhalt der Seite gehören. Im Falle von Wikisource (vermutlich auch bei der Wikipedia) sind das die Navigation oben und an der Seite, die Box mit den bibliografischen Angaben oben rechts (das hat mich am meisten verblüfft, da ich dachte die müsste ich später von Hand löschen), die Fußzeile und was es sonst noch so gibt an Elementen, die man in einem E-Book eher nicht haben möchte. Und er versucht die Struktur des Textes zu erkennen, denn aus den rein per Layout ausgezeichneten Überschriften im Text (fett und/oder etwas größer) werden richtige HTML-Überschriften. Das geht hier und da, insbesondere auf Titelseiten, daneben, was sich aber später leicht beheben lässt. HINWEIS: Möchte man die Links und Bilder aus dem Text bei Wikisource übernehmen, sollte man in den Einstellungen des Plugins die Einstellung „Immersive mode“ deaktivieren. Allerdings werden bei zuvielen Bildern alle entfernt und nur Platzhalter eingefügt.
  2. Dieses Grundgerüst eines E-Books, was man auch schon sofort verwenden könnte, kann man nun mit Hilfe des E-Book-Editors Sigil weiterbearbeiten und verfeinern. Sigil bietet einen WYSIWYG-Modus, man kann aber auch die XHTML-Dateien direkt bearbeiten, was hin und wieder sinnvoll sein kann. In Sigil habe ich bspw. die Titelseite angepasst, ein Coverbild ausgesucht oder Bilder wieder eingefügt, die dotEPUB rausgeworfen hat. Da der XHTML-Editor in Sigil eher rudimentär ist, hat mir ein WYSIWYG-HTML-Editor, wie z.B. Kompozer, gute Dienste geleistet, um die vielen Links die bei den Seitenzahlen auf die einzelnen Seiten zur Korrektur verweisen, zu entfernen. Die eigentliche Paginierung möchte man ja nach Möglichkeit erhalten. Weiterhin kann man hier die Metadaten des E-Books anpassen und ergänzen. Am besten macht man das direkt im entsprechenden XML-File, da die Oberfläche von Sigil hier noch etwas rudimentär ist. Alternativ kann man die Metadaten auch im nächsten Schritt ergänzen.Wichtig zu erwähnen ist noch eine Funktion von Sigil: die automatische Generierung eines Inhaltsverzeichnisses. dotEPUB generiert kein vollständiges Inhaltsverzeichnis, sondern nur ein rudimentäres mit Titelblatt, Inhalt und sogenanntem Disclaimer (enthält u.a. Hinweise auf den dotEPUB-Service, sollte man um dem kostenlosen Service die entsprechenden Meriten zuzugestehen einfach drin lassen). Die eigentliche Struktur des Textes kann man aber mit Sigil in Form eines vollständigen Inhaltsverzeichnisses automatisch aufbauen. Ein erster Schritt hierfür bietet die Funktion „Generate TOC from Headings“ rechts unten, was leicht zu übersehen ist. Sigil liest nun die HTML-Überschriften des Dokuments und versucht daraus ein Inhaltsverzeichnis zu basteln. Da ja dotEPUB dankenswerterweise schon einen Teil dieser Arbeit bei der Analyse und Generierung des E-Books übernommen hat, funktioniert das verblüffend gut. Man kann mit Sigil das E-Book noch viel mehr aufpeppen, als hier beschrieben, insbesondere bei Texten die bei Wikisource auf mehreren Unterseiten verteilt sind, wird es sicherlich noch seine Stärken ausspielen können. Wie bereits gesagt, über die dementsprechenden Erfahrungen werden ich später berichten.
  3. Der dritte und letzte Schritt ist notwendig, wenn man das E-Book für verschiedene Reader zur Verfügung stellen möchte. Der Kindle z.B. kann nur das Amazon-eigene Format AZW und das Format Mobipocket lesen und einige andere, aber eben nicht das EPUB-Format mit dem wir hier die ganze Zeit hantiert haben. Den Part der Konvertierung und der (weiteren) Ergänzung der Metadaten übernimmt Calibre. Calibre kann eine Vielzahl von Formaten ineinander umwandeln, bietet aber nur sehr eingeschränkte Möglichkeiten zur direkten Bearbeitung von E-Books. Außerdem ist es durch diverse Plugins erweiterbar und kann mit Hilfe dieser Plugins eine Vielzahl von Quellen aus dem Netz abrufen, für einen E-Reader aufbereiten und an diesen senden. Was ich zum Bsp. entdeckt habe, es gibt ein Plugin für Calibre, mit dem man den aktuellen Printspiegel (wenn man ein Abo hat oder wie ich Mitarbeiter des Spiegel-Verlages ist) herunterladen kann (verwendet wird dabei die Schnittstelle, die eigentlich für die IPad- und IPhone-App gedacht ist) und aufbereitet auf den Kindle senden kann. Das gelingt u.a. deshalb so gut, da die Spiegel-Apps intern ebenfalls das EPub-Format verwenden. Und das alles vollautomatisch und zeitgesteuert. HINWEIS: Für die Bearbeitung in Calibre wird das E-Book von Calibre in ein eigenes Verzeichnis kopiert (normalerweise $USER\Calibre Bibliothek). Wo sich die Datei auf dem eigenen Rechner befindet, kann man mit der Funktion „Öffne Speicherort“ erfahren, die über die rechte Maustaste beim Buch zu erreichen ist. Wenn man also an der ursprünglichen Version Änderungen vornimmt, merkt Calibre davon nichts. Bei mir hat sich deshalb bewährt das E-Book nach dem Herunterladen in Calibre zu importieren und erst diese importierte Version mit Sigil und Co. zu bearbeiten. Mit Calibre kann man die konvertierten E-Books, bzw. falls noch nicht konvertiert aber notwendig nach einer automatischen Konvertierung, dann bequem an seinen E-Reader senden oder so er mit dem Computer verbunden ist, direkt auf den Reader spielen. Im oben erwähnten Verzeichnis in das das E-Book importiert wurde, befinden sich nach der Konvertierung auch die anderen Formate.

Testweise habe ich heute zwei Texte auf Wikisource in E-Book umgewandelt. Zuerst einen einfachen Text ohne Bilder und Schnickschnack. Den historischen Aufsatz von Karl ZeumerDie Goldene Bulle Kaiser Karls IV. Erster Teil: Entstehung und Bedeutung der Goldenen Bulle. Die Erstellung des E-Books dauerte nur wenige Minuten und war wenig aufwändig. Als zweites habe ich mir das reich illustrierte Buch Ein kurtzweilig lesen von Dyl Vlenspiegel, einem der ersten Till-Eulenspiegel-Bücher, aus dem frühen 16. Jahrhundert vorgenommen. Hier gab es das Problem, dass der Text soviele Bilder enthält, dass dotEPUB streikte und anstelle der Bilder nur Platzhalter einfügte. Immerhin konnte man damit später die Bilder an der richtigen Stelle einfügen. Ansonsten wäre diese Nacharbeit wesentlich zeitaufenwändiger gewesen. Außerdem musste ich noch alle Links auf den Seitenzahlen die nach Wikisource verwiesen entfernen, was auch einige Zeit gebraucht hat. Insgesamt habe ich bei diesem Buch rund 4 Stunden benötigt. Wenn man das ganze Drumherum noch etwas sorgfältiger ausarbeiten und das Buch hübscher machen möchte, dann wird man wohl noch einiges mehr an Zeit investieren müssen.

Und nach all der Arbeit sieht dann auf meinem neuen Kindle eine Seite des Eulenspiegel-Buches so aus:

Screnshot KIndle mit Eulenspiegelbuch

Blöderweise kann man keines der E-Book-Format auf Commons oder ein anderes Wikimedia-Wiki hochladen (kann man das irgendwo beantragen?), weshalb eine Verlinkung des E-Books direkt in Wikisource erstmal nicht möglich ist. Deshalb werde ich die E-Books erstmal hier im Blog hosten. Und da ich aber nicht jedesmal wenn ich ein neues E-Book erstellt habe, diesen Blogbeitrag aktualiseren möchte, habe ich eine Seite in diesem Blog erstellt, die in Zukunft alle die von mir erstellten Bücher aufnehmen wird: [intlink id=“1298″ type=“page“]E-Books[/intlink]. Die ist im übrigen auch oben in der Navigation verlinkt.

Über Hinweise, Tricks, Kniffe und Erfahrungsberichte würde ich mich freuen. Und wenn jemand eigene E-Books aus Wikisource erstellt hat und weiß nicht wohin damit, dann lade ich die gerne hier hoch und bau sie in die oben erwähnte Liste mit ein.

Kleiner Vergleichstest Finereader 9 und Tesseract

Gestern wurde ich im Chat gefragt, welche OCR-Software ich empfehlen würde und da der Markt recht überschaubar ist und ich selbst seit einigen Jahren den Finereader einsetze und sehr zufrieden damit bin, blieben aus meiner Sicht eigentlich nur Finereader und als kostenlose Alternative Tesseract übrig.

Da mein Gegenüber etwas skeptisch war bezüglich der Qualität der von Finereader wurde ich gebeten eine Datei auf Commons mit einer Schreibmaschinenseite (Bild rechts) durch die OCR zu jagen. Und da zu einem Vergleichstest ja mindestens zwei gehören, war die gleiche Datei vorher bereits durch den Webservice Free OCR, der Tesseract verwendet, die Texterkennung durchgeführt worden.

Bei Free OCR kann man nur die Textsprache auswählen. Beim Finereader hab ich die OCR vollautomatisch ohne Auswahl der Textsprache oder eine Bildoptimierung durchführen lassen. Somit sollten die Ergebnisse sicherlich halbwegs vegleichbar sein. Ich habe derzeit den Finereader 9 in Benutzung. Vermutlich sähe das Ergebniss mit der aktuellen Version 10 nicht wesentlich anders aus.

Hier nun die Ergebnisse:

 Vergleich OCR-Ergebnis
Free OCR (Tesseract) Finereader 9
– I
§u*‘M~.. ‘ – , .’-‘J , ‘ms JOINT cl-uses or-‚ srass ‚
9* /f-<2» ~
‘Q _ _ wasmuoron fs.o.o.
-~~ .
i mmssnnw
IEMORMIDWKFOBTIESEOBMARYOFDEFENSE .‘ –
‘ Subject: Justification tor US Military Intervention
in cube (rs) ,-_- – .
‘ 1. ‘The Joint Chiefs of Staff have considered the attached
Memorandum“ for the Chief ’01‘ Operations, Cuba Project, which
responds to 3*-request of that office for brief but precise
‚ description of pretexts _which would provide Justification
for U8 military intervention in cube. _
H 2.‘ ‘the Joint Chiefs of staff recommend that the
proposed memorandum be forwarded as a preliminary submission
suitable for planning purposes. It is assumed that there
will be similar submissions from other agencies and that
these inputs will be used as a basis for developing a
_ time-phased plan. Individual projects can then be
considered on a case-by~case basis.
3. Further, it is assumed that a single agency will be
given the primary responsibility for developing military
and para-military aspects of the basic plan. It is
, recommended that _th:l.s responsibility for both overt and
-covert military operations be assigned the Joint Chiefs of
“ . – I . .
. _ . For the Joint Chiefs of Staff:
svsrsnnoua I ‚ ‘
BY J68 Ii}?! -5?‘ C aim“. -.“ – — _ –
msslr – … .‘ ‘ .
– L. L. LEMRITZER
‚ – _‘ _ Chairman ‚
‚ Joint Chiefs .01‘ S
l Enclosure . ‚ I –
Illemo for Ohio!‘ oi‘ Operations, Cuba. Project CXCI-UDED mom 00$
‚ ‚ . . p ‚_ sxcwnno non umamrc
_ Bmamllwz non DIR 5200.10
. _‘ _ – ‚ DOES NM‘ APPLY
~-
THE JOINT CHIEFS OF STAFF WASHINGTON £3, D.C.
1
13 March 196a
IffiMORAtfDUM FOR THE SECRETARY OF DEFENSE
Subject: Justification for US Military Intervention
1* The Joint Chiefs of Staff have considered the attached Memorandum-for the Chief of Operations, Cuba Project, which responds to aNr_equest of that office for brief but precise description of „pretexts which would provide justification for US military intervention in Cuba.
2. The .Joint Chiefs of Staff recommend that the proposed memorandum be forwarded as a preliminary submission suitable for planning purposes. It is assumed that there will be similar submissions from other agencies and that these inputs will be used as a basis for developing a time-phased plan. Individual projects can then be considered on a case-by-case basis.
3. Further, it is assumed that a single agency will be given the primary responsibility for developing military and para-military aspects of the basic plan. It is reoommended that this responsibility for both overt and covert military operations be assigned the Joint Chiefs of Staff,
in Cuba (TS)
For the Joint Chiefs of Staff:
1 Enclosure
Memo for Chief of
Operations, Cuba project
EXCLUDED fROM GD$
EXCLUDED PROff AUTOMAT IC BEGRADING; DOD DIR 5200,10 ¦ DOES NOT APPLY

Terese für Korrekturlesen von OCR-Texten

Screenshot Terese

Gestern wurde auf der Wikisource-Mailingliste auf Terese aufmerksam gemacht. Das Programm ist wohl noch in einer sehr frühen Entwicklungsphase (aktuelle Version 0.0.2) und steht unter der {de:GNU General Public License} und kann bei Sourceforge  heruntergeladen werden. Dort befindet sich auch eine ausführliche Installations- und Bedienungsanleitung.

Der Programmautor beschreibt das Programm folgendermaßen (Übersetzung von mir):

Terese is a tool which can be used to facilitate proofing the outcome of OCR programs, such as Tesseract. The basic idea is to try to map the OCR text to the original image. Differences, i.e. errors in the OCR text, are then easily identifiable.

(Deutsch: Terese ist ein Tool für Unterstützung beim Korrekturlesen der Ausgabe von OCR-Programmen, z.B. von Tesseract. Die grundlegende Idee dabei ist, den OCR-Text auf den  originalen Scan abzubilden. Unterschiede, z.B. Fehler im OCR-Text, sind somit leicht zu identifizieren.)

Ich habe Terese nicht ausprobiert, da ich Finereader benutze, wo die Funktionalität ja bereits eingebaut ist. Aber vll. kann ja jemand seine Erfahrungen mit Terese mitteilen.

Fraktur-OCR mit Tesseract

Die folgende Anleitung für Fraktur-OCR mit Tesseract unter Windows beruht auf einem Text von Jowinix in Wikisource. Ich habe den Text leicht überarbeitet und werde den Text noch mit ein paar Screenshots versehen. Wenn jemand bereits die kommerzielle OCR-Software Finereader auf der Platte hat, den möchte ich auf meinen älteren Artikel zur Fraktur-OCR mit Finereader verweisen.

Tesseract 3 ist eine Texterkennungssoftware, die aktuell von Google  weiterentwickelt wird und unter einer Open-Source-Lizenz steht und dementsprechend kostenlos verwendet werden kann. Tesseract wird auch für die Texterkennung bei Google Books verwendet und verarbeitet die folgenden Bildformate: tif, multipage tif, jpg, gif und png. Tesseract ermöglicht Texterkennung für mehr als 30 Sprachen, darunter auch Fraktur (Deutsch, Dänisch und Schwedisch). Das Programm liefert auch bei mehdrspaltigem Layout gute Ergebnisse. Allerdings ist keine grafische Benutzeroberfläche dabei (es gibt aber GUIs von Dritten) und das Layout der Seite geht komplett verloren, wobei letzteres für Wikisource kein Problem darstellt. Für die Durchführung der OCR muss man also ein klein wenig auf der Windows-Kommandozeile rumklimpern.

Windows Vista und Windows 7

Für die beiden neueren Betriebssysteme von Microsoft sind ein paar Dinge zu beachten, die ich an den entsprechenden Stellen entsprechend mit WINDOWS VISTA/7 markiert habe. Für Nutzer dieser Betriebssystem also diese entsprechenden Anmerkungen und Anweisungen unbedingt beachten.

Installation

Aus der Liste auf code.google.com lade man sich die folgenden ZIP-Dateien herunter: tesseract-ocr-setup-3.00.exe bzw. die jeweils aktuelle Version (das eigentliche Texterkennungsprogramm) und deu-frak.traineddata.gz (Sprachdatei Deutsch-Fraktur). Die Datei mit den Sprachdaten entpacken. Wenn man keinen passenden Entpacker für gz-Dateien an Bord hat, kann man sich in wenigen Minuten den kostenlosen und leistungsfähigen Entpacker 7-Zip installieren. Bei Bedarf können auch weitere Sprachdateien heruntergeladen werden und entpackt werden, die gängigsten Sprachen kann man sich aber auch später bei der  Installation hinzufügen.

Das heruntergeladene Installationsprogramm tesseract-ocr-setup-3.00.exe ausführen und Tesseract installieren. Bei der Installation kann man bzw. sollte man die deutschen Sprachdateien mitinstallieren, die sind aber erstmal nur für Antiqua-Schrift. Aber Texte die in Antiqua gesetzt wurden, will man ja auch durch die OCR jagen.

Den Ordner öffnen in dem Tesseract installiert wurde, das sollte normalerweise C:\Program Files\Tesseract-OCR sein, und in den Unterordner tessdata die entpackte Datei deu-frak.traineddata kopieren oder verschieben. WINDOWS VISTA/7: An dieser Stelle möchte Windows Adminstratorrechte haben, um die Kopieraktion durchführen zu können. Das muss bestätigt werden.

Jetzt ist Tesseract für Fraktur-OCR vorberereitet.

OCR durchführen

Die Scans (Bilddateien) die mit Tesseract verarbeitet werden sollen, können am einfachsten in den Ordner kopiert werden, in den Tesseract installiert wurde. WINDOWS VISTA/7: Auch hier fragt Windows wieder nach Administratorrechten, dies ebenfalls bestätigen.

Wem die Kopiererei in den Tesseract-Ordner und unter Win7 die Nachfragerei zu lästig ist, der kann sie auch in einem anderen Ordner belassen (bspw. c:\Bilder). In diesem Falle muss der Aufruf von Tesseract etwas angepasst werden.

Am besten eignen sich Scans mit 300 dpi und Graustufen.

Für die eigentliche OCR muss man die Windows-Kommandozeile aufrufen. Das geht mit: Windows-Taste+r, in die erscheinende Eingabezeile „cmd“ (ohne die Anführungszeichen) eingeben und Enter drücken. WINDOWS-VISTA/7:  Zum Start der Kommandozeile muss unbedingt Ctrl-Shift-Enter gedrückt werden, damit diese mit Adminstratorrechten ausgeführt wird. Alternativ kann die Kommandozeile wie in diesem Blogbeitrag angegeben aufgerufen werden, damit diese mit Adminstratorrechten ausgeführt wird.

In dem erscheinenden schwarzen Fenster mit blinkendem Cursor muss man nun zum Tesseract-OCR Verzeichnis wechseln. Das geht folgendermaßen (vorausgesetzt Tesseract ist im oben angegebenen Verzeichniss installiert). Nach jeder Zeile Enter drücken:

cd C:\
cd Programme
cd Tesseract-OCR

Nun geht es aber zur eigentlichen OCR. Damit Tesseract die OCR mit Fraktur durchführt, muss für Bild-Dateien im tif-Format folgende Zeile eingeben werden und Enter gedrückt werden:

for %i in (*.tif) do tesseract.exe %i %i -l deu-frak

Bei Dateien im jpg-, gif- oder png-Format muss der Befehl entsprechend geändert. Bei anderen Sprachen ist deu-frak durch das entsprechende Kürzel zu ersetzen: Deutsch=deu, English=eng usw. Wenn man die Dateien nicht in den Tesseract-Ordner kopiert hat, dann sieht der Aufruf entsprechend des obigen Beispielsordners in dem sich die Dateien befinden folgendermassen aus:

for %i in (c:\Bilder\*.tif) do tesseract.exe %i %i -l deu-frak

Das folgende Beispiel führt entsprechend eine OCR für Bilddateien im png-Format mit deutschem Antiqua-Text durch:

for %i in (*.png) do tesseract.exe %i %i -l deu

Das Programm arbeitet nun alle Scans im Stapel ab und erzeugt für jede Bilddatei eine Textdatei.

Die einzelnen Textdateien können mit:

copy /b *.txt Gesamttext.txt

zu einer großen Text-Datei zusammengefügt werden.

Weitere Informationen in englisch finden sich bei code.google.com.

AntiCommonist 0.4.0

Nach etwas längerer Zeit mal wieder ein kleines Update meiner beliebten kleinen Software zum Herunterladen von Bildern aus MediaWiki-Wikis.

Folgende Änderungen:

  • Die Option –m ob ein Verzeichnis neu angelegt wurde, hatte den falschen Default-Wert. Jetzt wird ein Verzeichnis automatisch angelegt, wenn das Verzeichnis noch nicht vorhanden ist. Vorher musste die Option, entgegen der Beschreibung, explizit auf true gesetzt werden. Das kann jetzt entfallen. Wenn allerdings dieses Verhalten nicht gewünscht wird, dann muss nun der Parameter auf false gesetzt werden.
  • Bei Netzwerk-Fehlern beim Herunterladen bricht AntiCommonist nicht mehr komplett ab und das Programm muss neu gestartet werden. Dies konnte insbesondere bei wackliger Internetverbindung oder zickigen Wikimedia-Server vorkommen. Nun versucht AntiCommonist das Bild standardmäßig drei mal herunterzuladen. Diese Verhalten kann mit der neuen Option –n gesteuert werden. Dieser übergibt man die Anzahl an Versuchen die AntiComminist verwenden soll, die Bilder herunterzuladen. Wenn innerhalb dieser Anzahl kein Erfolg erzielt werden konnte, geht AntiCommonist zum nächsten Bild über. Am Ende wird eine Liste der Bilder ausgegeben, die nicht heruntergeladen werden konnten.

Beschreibung der neuen Option:

-n,--numbertries    number of tries to download a file,
                    default is 3, values < 1 will
                    be set to equals 1

[download id=“9″]

AntiCommonist 0.3.0

Nach all den Bildern, Videos und langen Texten nun mal wieder ein einfaches und langweiliges Update des AntiCommonist.

Änderungen:

  • Die Auswertung der Kommandozeile wurde auf Apache Commons CLI 1.1 umgestellt, deshalb muss das Programm nun ein wenig anders aufgerufen werden. Im folgenden die möglichen Optionen:
usage: AntiCommonist [-c <categoryname>]
                     -d <localdirectory>
		     [-help]
		     [-m <true|false>]
		     [-t <textfile>]
                     [-w <wikiurl>]
 -c, --category <categoryname> download files from given
		               category, alternative
                               to option t
 -d, --dir <localdirectory>    local directory to save
                               downloaded files
 -help                         print this message
 -m, --makedir <true|false>    should local directory be
		               created if not exist,
                               default is true
 -t, --textfile <textfile>     name and path of file with
                               filenames to download from
                               wiki, alternative to
                               option c
 -w, --wiki <wikiurl>          url of wiki to download from,
                               if empty wikimedia commons
                               is used
  • Und wer nun aufmerksam das obige Kauderwelsch durchgelesen hat, wird festgestellt haben, dass eine Option hinzugekommen ist. AntiCommonist legt nun nämlich das lokale Verzeichnis für die heruntergeladenen Dateien an, wenn dieses noch nicht vorhandenen ist. Falls dies nicht gewünscht kann dies mit der neuen Option –m und dem Wert false abgeschaltet werden.

Die Umstellung des Programmaufrufes ist erforderlich geworden, da ich auch in Zukunft neue Optionen einfach hinzuzufügen möchte. Und da sich andere Leute schon einige Gedanken gemacht haben, wie man die Kommandozeile auswertet und ich das Rad nicht zum Millionstenmal neu erfinden muß, verwende ich ab sofort das Command Line Interface von Apache Commons. Daraus resultierend hat sich das Aufrufformat zum ersten und letzten Mal geändert. In Zukunft kommen nur neue Optionen hinzu.

Fraktur-OCR mit Finereader

Heute nun der versprochene Beitrag zu meinen Erfahrungen mit der OCR von Frakturschriften mit Finereader 9.

Finereader 9 ist die aktuellste Version des Finereader von Abbyy und eigentlich nicht für Fraktur-OCR vorgesehen. Aber da sich Abbyy den Finereader XIX der Fraktur von Haus aus vergolden lässt und man mit einer Lizenz nur eine beschränkte Anzahl von Seiten mit Frakturtext durch die OCR jagen kann, habe ich halt versucht es mit der normalen OCR durchzuführen. Und mit etwas Arbeit und hoffentlich diesen Tipps gelingt auch meist eine recht ordentliche Erkennung des Textes.

Vorbereitungen

Die wichtigste Voraussetzung sind natürlich gute Scans der zu erkennenden Seite. Am besten eignen sich nach meiner Erfahrung dafür Graustufen- oder Farbscans. Diese sollte man auch bevor man Finereader damit füttert nicht umwandeln. Die auf diversen Web-Seiten, insbesondere etwas ältere Digitalisate von Universitäten, zu findenden Schwarz-Weiß-Scans eignen sich meist weniger gut. Der Grund hierfür ist, dass Flecken, Fliegendreck u.ä. nach der Umwandlung in Schwarz-Weiß den gleichen Helligkeitswert (nämlich Schwarz) aufweisen wie die Nutzinformation und Finereader dann auch den Dreck ernst nimmt. Überlässt man die Auswertung des Bildes aber Finereader komplett, ist das Ergebnis wesentlich besser und der Dreck wird im Normalfall sehr gut ausgefiltert.

Beim Einscannen sehr dicker Bücher und fast immer beim Fotografieren mit einer Digicam wird der Text im Bereich der Bindung verzerrt, was für eine OCR tödlich ist. Zum Glück hat Abbyy in die Version 9 eine automatische Entzerrung eingebaut, die man aber auch manuell auslösen kann. Meine Versuche mit den vorhergehenden Versionen sind an diesem Problem gescheitert, da mit solchen Dokumenten kein vernünftiges Training möglich war.

Zu den Bildern selbst nur kurz, da diese Thema eines eigenen Beitrages werden sollen:

  • 300 dpi sollten es mindestens sein
  • bei Bilder mit einer Digicam reicht nach Aussage von Joergens die geringste Qualitätsstufe aus
  • 8 Bit Graustufen reichen für die OCR aus, weniger sollte es aber nicht sein

Training

Nachdem man alle Bildchen geladen hat, geht es mit dem Training der Software, im Finereader-Jargon „Benutzermuster testen” genannt, los. Dafür sind im Finereader-Dokument erst mal ein paar Einstellungen vorzunehmen.

Grundsätzlich sollte man die integrierten Muster für Antiqua-Schrift ausschalten, auch wenn etwas Antiqua im Frakturtext vorhanden ist. Denn sonst versucht Finereader, wenn es ein Zeichen nicht mit den trainierten Mustern erkannt hat, mit den eingebauten Mustern zu erkennen, was meist recht großen Murks ergibt. So werden gerne die großen Frakturbuchstaben als Copyright-Zeichen und anderen exotischen Sonderzeichen erkannt.

Im Menü Extras – Optionen – Tab Lesen nimmt man deshalb folgende Einstellungen vor:

  • Lesemodus: Gründlich
  • Benutzermuster testen bzw. Benutzermuster verwenden, wenn man schon trainiert hat
  • Bei „Integrierte Muster verwenden” das Häkchen entfernen

Das sollte dann also wie im folgenden Screenshot aussehen:

image

Zusätzlich sollte man über den Button „Mustereditor” sich eine eigene Musterdatei anlegen, die man entsprechend benennt, z.B. Fraktur o.ä. Den Grund hierfür erläutere ich später.

Dann kann man mit dem eigentlichen Training anfangen. Damit die nachfolgende dargestellte Box erscheint, muss unbedingt „Benutzermuster testen” ausgewählt sein. Man wählt sich also eine möglichst repräsentative Seite aus und fängt am besten mit einem Block Fließtext an, indem man „Seite lesen” oder „Bereich lesen” auswählt.

image

Der eigentliche Trainingsvorgang ist in der Hilfe recht gut beschrieben, so dass ich mir genauere Erläuterungen dazu spare. Nur ein Hinweis: Wenn man mitten in der Seite die Trainingsbox mit dem Button “Schließen” schließt, muss man vor einem erneuten Training in den Optionen wieder die Option “Benutzermuster testen” auswählen, da in diesem Fall Finereader den Trainingsmodus beendet.

Wichtig beim Training ist, dass man die OCR nicht übertrainiert. Als Übertraining bezeichne ich für mich persönlich den Versuch jedes gerade noch für den Menschen erkennbare Zeichen auch der Software beizubringen. Das bringt nichts, sondern verschmutzt quasi nur die Muster, so dass die Software nicht mehr weiß welches Zeichen denn nun wirklich vorliegt. Also deshalb verwischte, unvollständige, zusammenklumpende, nicht eindeutige Buchstaben am besten überspringen.

Dass man übertrainiert hat, bemerkt man daran, dass sich die Erkennungsleistung drastisch verschlechtert. Dann am besten komplett neu anfangen und vorsichtiger trainieren. Der Versuch die vermeintlich fehlerhaften Zeichen aus dem Muster zu löschen, bringt nach meiner Erfahrung nichts, da nicht erkennbar ist welche Zeichen tatsächlich die Probleme verursachen. Vermutlich verwendet Finereader zusätzlich zu den für den Nutzer einsehbaren Mustern, noch viel mehr Informationen, die die Erkennung beeinflussen.

Genauso sollte man nicht versuchen der Software krampfhaft beizubringen sehr ähnliche Zeichen zu unterscheiden. So werden gern u und n, das lange s und f verwechselt. Hier meine Empfehlung prototypische und gut erkennbare Zeichen zu trainieren und bei offensichtlichen Fehlern, die Software zu korrigieren. Ansonsten die Buchstaben überspringen. Alles andere bringt mehr Frust und Arbeit, aber keine wesentlich bessere Erkennungsleistung. Eher im Gegenteil besteht auch hier die Gefahr des Übertrainierens.

Was sehr gute Resultate, besonders bei etwas schlechteren Vorlagen, bringt, ist das exzessive Training von Ligaturen, auch wenn es eigentlich keine sind. Zuerst natürlich die in Frakturschrift häufig anzutreffenden Verbindungen von s und t und langes s und i, sowie f und i, t und z u.ä. Weiterhin wird man während des Trainings feststellen, dass einem Finereader immer wieder die gleichen Buchstabenkombinationen als ein Zeichen vorschlägt. In solchen Fällen einfach eine neue Ligatur anlegen und die gesamte Buchstabengruppe in Zukunft zusammen erkennen lassen.

Das kann bis zur Anlage eines ganzen Wortes wie „und” als Ligatur gehen. Ein Vorteil von Ligaturen ist auch, dass sich durch die erhöhte Anzahl der Buchstaben, und damit an signifikanten Merkmalen, die Treffergenauigkeit wesentlich erhöht. Wenn man also das Wort „und” als Ligatur trainiert hat, weil die Buchstaben immer gern aneinanderkleben, dann kommt eine Verwechslung von u und n zumindest in diesem Wort wesentlich seltener vor.

Was sollte extra trainiert werden:

  • Antiquaschrift, falls solche im Text vorkommt
  • Zahlen
  • Sonderzeichen, wie Klammern, Semikolons etc.

Für diese Zeichen also schauen wo sie etwas gehäufter vorkommen und dann diesen Bereich trainieren. Der Einfachheit halber kann man auch einen extra Bereich manuell anlegen, damit man nicht erst eine halbe Seite trainieren muss, um zu der gewissen Stelle zu gelangen. Den Bereich kann man nach dem Training wieder löschen.

Zu beachten ist außerdem, dass für unterschiedliche Schriftgrößen (Überschriften, Fußnoten etc.) sehr oft unterschiedliche Schriften eingesetzt wurden. In solchen Fällen muss man dann auch diese Bereiche extra trainieren. Wenn die Schrift allerdings nur an einigen wenigen Stellen, z.B. der Titelseite, vorkommt, dann sollte man sich die Arbeit sparen. Abtippen ist da meist schneller.

Wenn man der Meinung ist, dass die OCR eine ausreichend große Anzahl an Buchstaben erkennt, kann man das ganze Dokument oder wahlweise einzelnen Seiten komplett durch die OCR jagen. Wenn sich dabei an einigen Stellen Probleme ergeben, z.B. wegen wechselnder Schrift oder anderer Schriftgröße, muss man diese Stellen nachtrainieren. Anschließend sollte man dann das ganze Dokument neu erkennen lassen.

Nach meiner Erfahrung gelingt eine gute OCR nach etwa 1 bis 3 Stunden Training, je nach Qualität der Vorlage. Manchmal bekommt man aber selbst nach stundenlangem Training nichts Vernünftiges hin. Da hilft dann nur Abtippen.

Nachbereitung

Da die OCR, wie oben bereits angedeutet, immer mal wieder gern Buchstaben verwechselt, sollte man nach der OCR eine Textersetzung drüberlaufen lassen, die zumindest die gröbsten und häufigsten Fehlerkennungen ersetzt. Das Resultat ist dann schon meist ein recht gut lesbarer Text. Bei mir erledigt das vor dem Hochladen nach Wikisource mein Bot, der auch gleich die dazugehörigen Seiten anlegt und mit der OCR füllt.

Wiederverwendung

Schön ist, dass man die Musterdateien mit den trainierten Zeichen wiederverwenden kann. Das lohnt sich insbesondere bei der OCR mehrerer Bände eines Werks oder Jahrgängen von Zeitschriften. Aber auch bei unterschiedlichen Büchern lohnt nach meiner Erfahrung die Wiederverwendung, da sich die Trainingszeit, zumindest bei ähnlicher Schrift, dadurch drastisch verringern lässt. Schaden tut die Wiederverwendung aber auf keinen Fall. Im schlechtesten Fall muss man die verwendete Frakturschrift komplett neu trainieren, was man aber auch so hätte tun müssen.

Die Wiederverwendung geht leider nicht direkt über die Oberfläche, aber mit wenigen Handgriffen. Am einfachsten ist es ein älteres Fraktur-Projekt zu laden und unter neuem Namen zu speichern und anschließend die alten Bilder aus dem neuen Projekt zu löschen.

Als Alternative legt man sich einfach ein neues Projekt an, speichert es und kopiert aus einem älteren Frakturprojekt die Datei mit der Endung *.ptn in den neuen Projektordner. Und wenn wir oben dem Benutzermuster den Namen „Fraktur” gegeben haben, dann heißt die dazugehörige Datei fraktur.ptn. Deshalb die Empfehlung dem Benutzermuster einen Namen zu geben. Ansonsten landet die PTN-Datei nämlich in irgendeinem temporären Verzeichnis in den Tiefen der Festplatte. Im Anschluss muss man die kopierte Musterdatei noch aktivieren. Das geht mit Hilfe des Buttons „Mustereditors” in den Optionen (siehe oben den ersten Screenshot).

Fazit

Bei guten Vorlagen mit Texten aus dem späten 18. und 19. Jahrhundert, die maschinell gesetzt wurden und einheitliche Schriften innerhalb des Textes verwenden, ist meist eine akzeptable Qualität erreichbar. Die Texte müssen selbstverständlich noch korrigiert werden, um wirklich vorzeigbar zu sein.

Bei früheren Texten bin ich bisher gescheitert, da die Jungs damals sehr oft ziemlich wahllos in ihren Setzkasten griffen und für ein denselben Buchstaben Typen aus verschiedenen Schriften verwendeten, womit kaum ein vernünftiges Training möglich ist. Hinzu kommen krumme und schiefe Zeilen, unterschiedliche Zeichenabstände, ineinander ragende Zeilen und ähnliches. In solchen Fällen ist man mit dem Abtippen meist besser bedient.

Über Ergänzungen, Korrekturen oder Erfahrungsberichte zur Fraktur-OCR mit Finereader oder anderer Software würde ich mich freuen und gern hier veröffentlichen.

AntiCommonist 0.2.1

Auch auf die Gefahr hin, dass es derzeit etwas monothematisch ist, muss ich heute doch wieder was zum AntiCommonist schreiben, da es eine neue fehlerbereinigte Version gibt.

Änderungen

  • Fehler bereinigt beim Download aus Kategorien, bisher stolperte AntiCommonist über Artikel, Vorlagen etc. die in einer Kategorie enthalten waren
  • Fehler in der Batch-Datei behoben
  • Integration der aktuellen Version des JavaWikiBotFrameworks

 

Download AntiCommonist 0.2.1

AntiCommonist 0.2

Nachdem zum AntiCommonist ein paar Hinweise und Wünsche eingegangen sind, hier nun eine neue Version.

Änderungen

  • Es sollte nun das Bild in der höchsten Auflösung unabhängig von der Sprache gefunden werden (Dank an Dapete für den Hinweis auf die API-Funktion)
  • Man kann jetzt auch Bilder aus einer Kategorie herunterladen. Der Aufruf dafür lautet:
anticommonist -category <categoryName> <downloadPath> <wiki>

categoryName – Name der Kategorie, ohne Category: oder Kategorie: oder wie die in anderen Sprachen auch immer benamst werden

downloadPath – lokaler Pfad in dem die Bilder abgelegt werden sollen

wiki – von welchem Wiki soll herunter geladen werden, Angabe in der Form: http://commons.wikimedia.org. Darf weggelassen werden. Dann wird Commons verwendet.

  • Kleinen Fehler in der Batchdatei behoben

Download AntiCommonist 0.2

AntiCommonist

Update: Dieser Beitrag beschreibt die erste Version des Tools, die aktuelle Version kann hier heruntergeladen werden.

Bilder auf Commons hochzuladen geht ja dank Commonist schon seit einer Weile recht komfortabel. Was aber machen, wenn man sehr viele Bilder von Commons in der höchsten Auflösung herunterladen will, z.B. ein komplettes Buch mit über 500 Seiten? Klicken und speichern macht nicht wirklich Spaß und dauert eine halbe Ewigkeit.

Eine Lösung war bisher das Tool Winpluck von Flominator, welches aus meiner Sicht ein paar Unschönheiten hat. Zum Beispiel benötigt man einen Apache mit PHP. Außerdem lädt es derzeit das falsche Bild herunter, weil die Jungs auf Commons so pffifig waren, ein Bild in die Sitenotice einzubauen und Winpluck einfach nach dem ersten Bild in der HTML-Seite suchte. Außerdem mag ich PHP nicht ;-)

Deshalb habe ich das neckische Tool einfach nachgebaut und mit paar zusätzlichen Features versehen:

  • läuft mit Java lokal auf dem Rechner in der Kommandozeile
  • es wird auf der Commons-Seite explizit nach der großen Version des Bildes gesucht, so dass die Commons-Admins und Entwickler die Seiten mit anderen Bildern vollpflastern können wie sie wollen.
  • Die Dateien werden mit dem korrekten Dateinamen abgespeichert und nicht wie Winpluck mit UTF-codierten Zeichen

Verwendung

AntiCommonist liest eine einfache Textdatei mit Dateinamen ein. In jeder Zeile steht ein Name, ohne Präfix File:, Datei:, Bild: oder ähnliches. Beispiel:

Reichs-Ritter-Archiv_I_0001.jpg
Reichs-Ritter-Archiv_I_0002.jpg
usw.

Eine Batchdatei zum Aufruf ist beigelegt. Auf der Kommandozeile folgendermaßen aufrufen:

anticommonist <textfile> <downloadPath> <wiki>

textfile – Dateiname inklusive Pfad, der Textdatei die die Dateinamen auf commons enthält

downloadPath – lokaler Pfad in dem die Bilder abgelegt werden sollen

wiki – von welchem Wiki soll herunter geladen werden, Angabe in der Form: http://commons.wikimedia.org. Darf weggelassen werden. Dann wird Commons verwendet.

Zu Ausführung wird Java 1.6 benötigt.

Download AntiCommonist 0.1.1

Für Hinweise, Fehlermeldungen, Anregungen etc. bin ich natürlich dankbar.

Update

Mittlerweilen habe ich eine neue Version hochgeladen, die einige kleinere Fehler beseitigt:

  • Batch-Datei wechselt nicht mehr in das übergeordnete Verzeichnis
  • Download nun auch von deutschsprachigen Wikis möglich, andere Sprachen müssen allerdings weiterhin manuell hinzugefügt werden. Ich werde mir aber eine sprachunabhängige Lösung überlegen, wie ich den Link zur hochaufgelösten Version in der Datei-Seite finde.

Eine ausführliche Anleitung werde ich demnächst der Zip-Datei hinzufügen.

Kein Versehen mehr

Autor: Jerry7171, cc-by-sa 2.0
Fotograf: Jerry7171, CC-BY-SA 2.0

Frank hat mich gestern auf eine interessante Mediawiki-Erweiterung aufmerksam gemacht, die sich derzeit auf dem Testwiki in der Erprobung befindet. Demnächst gibt es keine Entschuldigung mehr, wenn einem aus Versehen, oder weil Katze, Hund oder sonstiges Hausgetier über die Tastatur latschen, ein Artikelentwurf verloren geht. Denn Trevor Parscal, der neue Software Entwickler der Foundation, hat die sogenannte Draft Extension geschrieben, also eine Erweiterung für Artikelentwürfe.

Bei Bearbeitung eines Artikels  wird alle 2 Minuten automatisch ein Entwurf gespeichert und ist nach einem eventuellen Mißgeschick auf der Edit-Seite des entsprechenden Artikels wieder abrufbar. Außerdem können alle eigenen Entwürfe auf einer Spezialseite eingesehen werden. Nicht endgültig abgespeicherte Entwürfe werden nach 30 Tagen entfernt. Es wird also  keine Datenmüllhalde angelegt.

Weiter Einzelheiten und Screenshot kann man im Blog von leŭksman nachlesen.

Prinzlich konvertieren

Bild aus Des Freyherrn von Münchhausen Wunderbare Reisen Vor ein paar Tagen hatte Matthias Schindler auf der Wikipedia-Mailingliste auf PrinceXML aufmerksam gemacht, mit dem nach seiner Meinung schnell und einfach ein PDF aus einer Wiki-Seite (eigentlich aus jeder beliebigen HTML-Seite) erstellt werden kann. Und dem Mann kann man voll und ganz recht geben. Er monierte nur einige Unschönheiten im Rendering. Die lassen sich aber größtenteils mit einem eigenen CSS ausbügeln, das man dem Tool zum Fraß vorwirft.

Ein solches CSS habe ich auf Grundlage des normalen Print-CSS von Mediawiki erstellt und einige Optimierungen, vorrangig für Wikisource, aber auch allgemeingültige, eingebaut. Das CSS ist inklusive einer kleinen Anleitung auf einer Seite in meinem Benutzernamensraum in Wikisource zu finden. Hier die Dinge, die ich geändert habe:

  • Textbox bei Wikisource ist raus (allgemein gesprochen alles was die class noprint besitzt)
  • Kategorien sind raus
  • Fußzeile ist raus
  • Fußnoten sind reiner Text, also nicht mit mehr mit dem Wiki verlinkt
  • Pfeil nach oben in den references entfernt, der auch auf das Wiki verlinkte
  • (wenn mir jemand sagt wie man in CSS Texte ersetzen kann, dann verlinke ich die Fußnoten oben und unten wieder miteinander)
  • Weiterleitungshinweise werden nicht angezeigt
  • Blabla „aus Wikisource, der freien Quellensammlung“ (bzw. der Spruch des entsprechenden Projektes) wird unterhalb des Titel nicht angezeigt
  • und noch ein paar andere Wikisource-spezifische Anpassungen

Und da man Wikisource ja erstmal die in der Software eingebaute PDF-Lösung vorenthält, müssen wir uns erstmal damit begnügen und es sind auch scon ein paar sehr schöne PDFs generiert worden. Als Beispiel das mit PrinceXML generierte PDF (6,69 MB, so groß weil Bilder enthalten sind) von Des Freyherrn von Münchhausen Wunderbare Reisen, das Paulis erstellt hat.

Ich denke mal, dass wir auf diese Art und Weise in den nächsten Wochen eine Vielzahl von PDFs für die Texte in Wikisource erstellen und damit einen weiteren Nutzen für die Leser bieten können. Alle vorhandenen PDFs mit Volltexten finden sich auf der Seite Wikisource: Download, die zwar schon eine geraume Weile existiert, aber bisher eher dahin dümpelte.