Mai 11
Dieser Eintrag ist Teil 7 von 7 in der Artikelserie AntiCommonist

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 AntiCommonist 0.4.0

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertungen vorhanden)
Loading ... Loading ...
Tags:
Feb 25
Dieser Eintrag ist Teil 6 von 7 in der Artikelserie AntiCommonist

Dies ist ein kleines Bugfix Release.

Änderung:

  • Parameter –m wird jetzt korrekt ausgewertet, dieser wurde zuvor komplett ignoriert
  • Kleine Verbesserung in der Batchdatei bezüglich der Weitergabe der Parameter

Download AntiCommonist 0.3.1

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertungen vorhanden)
Loading ... Loading ...
Tags:
Feb 18
Dieser Eintrag ist Teil 5 von 7 in der Artikelserie AntiCommonist

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.

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (2 mal bewertet, durchschnittliche Bewertung: 4.00
Loading ... Loading ...
Tags:
Feb 09

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.

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (3 mal bewertet, durchschnittliche Bewertung: 4.67
Loading ... Loading ...
Tags:
Feb 07
Dieser Eintrag ist Teil 4 von 7 in der Artikelserie AntiCommonist

Heute mal wieder eine neue Version des AntiCommonist.

Änderung:

  • Bereits heruntergeladene Dateien werden nun nach einem Neustart nicht erneut heruntergeladen, sondern übersprungen. Spart Zeit und Serverlast, falls aus irgendeinem Grunde der Download unterbrochen werden musste.
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertungen vorhanden)
Loading ... Loading ...
Tags:
Feb 02

Der AntiCommonist kann ja seit der Version 0.2.1. Bilder auch aus einer Kategorie herunterladen. Wer es lieber per Python mache möchte, der sei auf dieses Skript von Christoph verwiesen. Danke an ihn für den Hinweis.

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertungen vorhanden)
Loading ... Loading ...
Tags:
Jan 22
Dieser Eintrag ist Teil 3 von 7 in der Artikelserie AntiCommonist

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

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertungen vorhanden)
Loading ... Loading ...
Tags:
Jan 21
Dieser Eintrag ist Teil 2 von 7 in der Artikelserie AntiCommonist

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

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (2 mal bewertet, durchschnittliche Bewertung: 5.00
Loading ... Loading ...
Tags:
Jan 20
Dieser Eintrag ist Teil 1 von 7 in der Artikelserie 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.

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (4 mal bewertet, durchschnittliche Bewertung: 5.00
Loading ... Loading ...
Tags:
Jan 18
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.

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (1 mal bewertet, durchschnittliche Bewertung: 4.00
Loading ... Loading ...
Jan 16

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.

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (2 mal bewertet, durchschnittliche Bewertung: 5.00
Loading ... Loading ...
Tags:
preload preload preload