staging.inyokaproject.org

Hi!

ExactImage ist imho eine echte Alternative zu ImageMagick, und speziell für den Bereich OCR-Vorbereitung und Archivierung konzipiert worden.

Ich hab' leider die manuelle Installation von Version 0.7.5 und 0.8.0 nicht hinbekommen; auch an dem verlinkten Bug in libagg scheint niemand zu arbeiten. Ggf. schreibe ich die exactCODE-Leute mal an, ob die Rat wissen.

Vielleicht schaffe ich es auch noch, eine ExactImage-Version zu Gescannte Dokumente nachbessern als Beispiel zusammenzubauen und die Zeit zu vergleichen...

Ansonsten bin ich so weit fertig; Anmerkungen, Konstruktive Kritik, Ergänzungen etc pp. wie immer willkommen! ☺

so long
hank

Hi!

Heinrich Schwietering schrieb:

...Anmerkungen, Konstruktive Kritik, Ergänzungen etc pp. wie immer willkommen! ☺

Aber doch bitte nicht so viel, komme ja kaum nach mit dem Lesen...

so long
hank

Hallo,

ok, wenn du es willst:

• Wo kommt den die Schweizer Flagge her? IMHO ist die nicht "offiziell". Abgesehen davon hat die Schweiz vier offizielle Sprachen, wenn ich mich nicht ganz irre...

• Der 2. Satz unter "unterstützte Dateiformate" ist ein bissl lang und durch die vielen Klammer schwer zu lesen. Mach' da doch mal 2 oder 3 draus.

• "optimize2bw - Ein mächtiger Befehl zum Erstellen von Archivdateien oder Vorlagen" → was für Archivdateien? tar & Co. sind wohl nicht gemeint...

Sonst ganz passabel 😀

Gruß, noisefloor

Hi!

Na, es liest also tatsächlich jemand... 😈

noisefloor schrieb:

• Wo kommt den die Schweizer Flagge her? IMHO ist die nicht "offiziell". Abgesehen davon hat die Schweiz vier offizielle Sprachen, wenn ich mich nicht ganz irre...

Die Schweizer Flagge lässt sich aber doch ganz einfach produzieren

{ch}

schon ist sie da: 🇨🇭, muss also ja vorgesehen sein 😉

• Der 2. Satz unter "unterstützte Dateiformate" ist ein bissl lang und durch die vielen Klammer schwer zu lesen. Mach' da doch mal 2 oder 3 draus.

Bandwurmsätze produziere ich, seit ich sprechen kann. Normalerweise korrigiert aasche das früher oder später; besonders, wenn ich Semikola verwende 😬 - (gefixt)

• "optimize2bw - Ein mächtiger Befehl zum Erstellen von Archivdateien oder Vorlagen" → was für Archivdateien? tar & Co. sind wohl nicht gemeint...

"Archivdateien", nicht "Datei-Archive" - die archivierten Wiki-Artikel sind ja auch keine tar.gzs... 😊 (aber OK, sind jetzt "Dateien zur speicherplatzsparenden Archivierung")

Sonst ganz passabel 😀

Na, geht doch 😀 ! "duckundwegrenn"

Hab' auch noch das pdfocr-PPA gefunden, da ist eine aktuelle Version (0.8.0) drin; die ExactCode-Leute hüllen sich noch in Schweigen.

Verschiebe das also demnächst.

so long
hank

Hi!

Wie angedroht: Verschoben ExactImage 😛 und passend verlinkt.

so long
hank

Als gelöst markiert. 😛

Hi!

Ach ja, komm doch zurück... 😇

so long
hank

hocr2pdf

Ich habe das Paket exactimage unter Linux Mint 17 (Ubuntu 14.04 LTS) aus den Quellen installiert, später auch nochmal komplett deinstalliert und aus dem Sourcecode compiliert. Das Paket ließ sich mit etlichen Warnings letztlich ohne Probleme compilieren. Ich bin der Anleitung hier gefolgt: http://www.auxnet.de/cuneiform-und-hocr2pdf-unter-ubuntulinux-installieren-und-einsetzen/, allerdings musste ich libungif4-dev aus dem install subversion Kommando entfernen und musste dann feststellen, dass ich keinen Zugriff auf das svn habe. Letztlich habe ich dann den Download Link auf der vorliegenden WiKi-Seite genutzt.

Ich nutze ein für meine Bedürfnisse angepasstes Script von Konrad Voelkl (http://www.konradvoelkel.com/2013/03/scan-to-pdfa/), dort wird tesseract für die OCR-Texterkennung verwendet (aktuelles tesseract Paket habe ich aus den Quellen installiert). Der Fehler mit den großen Schriften tritt leider auch in der Zusammenarbeit mit tesseract auf; von daher ist diese Kombination - anders als im Text der Seite angegeben - offenbar keine Lösung.

Hier ein Beispiel-Abschnitt aus der hocr Datei zum erkannten Text "Herrn", der viel zu groß dargestellt wird:

<span class='ocrx_word' id='word_1_46' title='bbox 720 1871 832 1904; x_wconf 81' lang='deu' dir='ltr'><strong>Herrn</strong></span>

Ich sehe einerseits das <strong> Tag, das nach meinem Kenntnisstand aber nur Fettdruck auslöst, andererseits eine Eigenschaft x_wconf, die ich nicht kenne, die aber vielleicht für die Formatierung des Wortes mitverantwortlich ist. Weiß jemand mehr darüber? Vielleicht könnte ich mit einem Skript die HTML-Tags nachbearbeiten und unnötige Formatierung entfernen.

Hi!

Das Problem findest du in der Dimension der Box "bbox 720 1871 832 1904"; wie man das automatisiert auf ein vernünftigen Maß zurückführt, wüsste ich auch gerne...

Ich empfehle momentan OCRmyPDF, das gibt die beste Kennung bzw Passung, die aktuelle gscan2pdf-Version aus dem PPA des Entwicklers sollte auch ganz vernünftige Ergebnisse liefern.

so long
hank