staging.inyokaproject.org

Hi!

OCRmyPDF: Auf Hinweis von aasche (in den Wiki/Artikelideen, keine Ahnung, warum er mich da als Ideengeber reingeschrieben hat, vielleicht weils "mein" Metier ist 😉 ) noch ein - anscheinend sehr zuverlässiges - Programm zur Textlagenerstellung für PDF-Dateien, Ausgabe in PDF/A. Momentan keine Installation vorgesehen, muss auch noch ein wenig testen, vielleicht könnte das noch jemand sonst versuchen?

Leicht OT: Wo baue ich den ggf. mal einen direkten Vergleich mit Ergebnissen zwischen den ganzen pdf-ocr-Programmen ein, die sich so angesammelt haben? Eine Art Übersichtsseite dazu erstellen, und von Texterkennung und PDF drauf verlinken?

so long
hank

Momentan keine Installation vorgesehen, muss auch noch ein wenig testen, vielleicht könnte das noch jemand sonst versuchen?

Ich habe mir momentan sehr viel vorgenommen , das paßt derzeit schlecht in meinen Zeitplan. 😉 Unter Optionen ist noch ein kleiner Syntaxfehler (-h ).

Leicht OT: Wo baue ich den ggf. mal einen direkten Vergleich mit Ergebnissen zwischen den ganzen pdf-ocr-Programmen ein, die sich so angesammelt haben? Eine Art Übersichtsseite dazu erstellen, und von Texterkennung und PDF drauf verlinken?

Macht Sinn - wobei solch eine Seite immer gepflegt werden muss...

Hi!

testing, testing...Ooops, da liegen Anspruch und Wirklichkeit wohl "etwas" auseinander... Mal sehen, ob ich 'ne eingescannte PDF hinbekomme, mit der das Teil funktioniert....

EDIT: precise scheint schlicht "zu alt" zu sein, unter saucy läuft das mit 1.0-stable (fast) wie geschmiert. Gibt nur eine seltsame Meldungen, bei bunten Vorlagen:

OCRmyPDF.sh: 232: [: sRGB: unexpected operator

bzw bei schwarzweißen:

OCRmyPDF.sh: 232: [: Gray: unexpected operator

EDIT 2 Problem ist in Version 2.x auch gelöst, lag an Inkompatibilitäten zwischen sh und bash... Getestet Precise also raus, jetzt muss ich nur noch an der systemweiten Verwendung prokeln; es gibt aber wohl eine config-Datei, in der die Pfade angegeben werden können, dann sollte es auch über /usr/local/share/ laufen können...

so long
hank

Hi!

Puh, was ein Fummelkram mit der "systemweiten" Installation 😮 ... Hoffentlich erbarmt sich bald jemand des Programms und baut Pakete dafür 😉.

Die Ergebnisse sind allerdings echt das beste, was ich bisher an Texterkennung für PDFs gesehen hab. 👍, Schade das es unter precise nicht so richtig hinhaut.

Soweit wäre ich also durch; aber vielleicht gibt es elegantere Lösungen für den Fummelkram?

so long
hank

Hi!

Na, wenn's nichts mehr dazu gibt, verschieb' ich das mal: OCRmyPDF ☺ .

so long
hank

Hi

Vieleicht habe ich doch was dazu. Wenn ich die stabile Version von OCRmyPDF aufrufe (egal ob nach systemweiter "Installation" oder aus dem Ordner heraus in den ich es runtergeladen habe), dann erscheint folgendes:

Killerkaninchen@Killerkaninchen-desktop:~$ /home/Killerkaninchen/Downloads/OCRmyPDF-1.0-stable/OCRmyPDF.sh /home/Killerkaninchen/Lieferschein.pdf /home/Killerkaninchen/Lieferscheintest.pdf 
ls: Zugriff auf ./tmp/20140104_1429.filename.Lieferschein/0001_Image* nicht möglich: Datei oder Verzeichnis nicht gefunden
Expecting exactly 1 image on page 0001 (found 0). Exiting...

Egal welche Option ich angebe, mit Anführungszeichen oder ohne usw...

Die Dateien page-sizes.txt und tmp.txt werden im tmp-Ordner angelegt. Die page-sizes.txt zum Beispiel mit folgendem Inhalt:

0001 612 792
0002 612 792

In der Version 2.x heißt die erste Datei pages-info.txt. Der Inhalt ist aber identisch.

Bei dem Projekt selber bin ich nur darauf gestoßen, dass das Zeichen # im Namen für einen Absturz des Skriptes sorgt (https://github.com/fritz-hh/OCRmyPDF/issues/34). Das trifft auf meine PDF ja nicht zu. Auf andere Infos bin ich im Netz nicht gestoßen.

Die im Artikel angegebenen Pakete sind installiert.

Mit der Version 2.x scheint es zu funktionieren, obwohl teilweise die selbe Fehlermeldung auftritt:

Killerkaninchen@Killerkaninchen-desktop:~$ /home/Killerkaninchen/Downloads/OCRmyPDF-2.x/OCRmyPDF.sh /home/Killerkaninchen/Lieferschein.pdf /home/Killerkaninchen/Lieferscheintest.pdf 
ls: Zugriff auf ./tmp/20140104_1436.filename.Lieferschein/0001_Image* nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: das Entfernen von »./tmp/20140104_1436.filename.Lieferschein/0001_Image*.*“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Page 0001: Expecting exactly 1 image on page 0001 (found 0). Page might not (only) contain a scanned image !!!
Page 0001: Continuing anyway, assuming a default resolution of 300 dpi
ls: Zugriff auf ./tmp/20140104_1436.filename.Lieferschein/0002_Image* nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: das Entfernen von »./tmp/20140104_1436.filename.Lieferschein/0002_Image*.*“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Page 0002: Expecting exactly 1 image on page 0002 (found 0). Page might not (only) contain a scanned image !!!
Page 0002: Continuing anyway, assuming a default resolution of 300 dpi

Vielleicht weiß ja jemand, wie man die stabiel Version nutzen kann, denn die ist ja schließlich zu bevorzugen...

Gruß Killerkaninchen

Hi!

Das Problem scheint in deiner PDF-Datei begründet zu sein. Was ist es für eine Datei, von welchem Programm erstellt? Kannst du es anderweitig konvertieren? Geht es mit z.B. von XSane erstellten PDFs? (Und auf was für einem Rechner bzw. Ubuntu-Version läuft das bei dir?)

so long
hank

Ich nutze Ubuntu 13.10. Das Dokument scheint im Grunde genommen ein Word-Dokument zu sein...?! (Steht zumindest in Okular mit der Endung .doc)

Habe jetzt mal ein bischen gestestet:

Mittels LibreOffice Writer erstellte PDFs funktionieren nicht (gleiche Fehlermeldung). Ich habe keine (Word-)Textdateien importiert, sondern zu Testzwecken aus meinem ersten Post hier gerade eine PDF-Datei erstellt.

Zudem habe ich noch eine weitere Test-Datei ohne jegliche Sonderzeichen erstellt. Das selbe Ergebnis...

Ein mit xsane als PDF abgespeicherter Artikel hat dagegen funktioniert.

Version 2.x macht bei keiner der Dateien Probleme...

EDIT: Mittlerweile ist mein Rechner auch damit fertig eine 1,3MB große Datei zu bearbeiten. Sie funktioniert einwandfrei ist aber jetzt 209MB groß und das ganze hat 40 Minuten gedauert (3,5GB RAM, AMD Athlon 64 X2 4600+ - also nicht mehr ganz taufrisch...). Könnte ja auch ganz interessant sein...?

Hi!

Hm, eigentlich ist das Programm nur für PDF-Dateien ohne Text sinnvoll (also z.B. selbstgescannte), ein PDF, was du per Windows (EDIT Word z.B.), oder mit LibreOffice erstellst, ist per se "durchsuchbar", braucht also keine extra Textlage, und ist insofern auch kein "grafisches" PDF. Ich kann mir vorstellen, dass Version 2.x das einfach erkennt, und nur in PDF/A umformt, während die stable-Version damit Probleme hat, weil kein "Bild" gefunden wird (wie deine Fehlermeldung ja zeigt...)

so long
hank

Dann hatte ich es wohl falsch verstanden. (Habe mich beim Ausprobieren allerdings auch etwas gewundert...)

Hi!

Hab' noch einen entsprechenden Hinweis wg. der PDFs aus Textbearbeitungsprogrammen eingefügt; das gilt natürlich auch für andere Pdf2Ocr-Programme (hatten das Thema soweit ich mich erinnere auch anderswo schon mal so ähnlich, sollte also wohl auch auf der Texterkennungsseite einen Hinweis zu den PDF-Programmmen einbauen.)

so long
hank

Hi!

Mit dem EOL von Saucy derzeit ungetestet; werde es die Tage mit Trusty versuchen.

so long
hank

Hi!

Geht auch unter Trusty, habe die "systemweite Installation" jetzt ein bisschen einfacher hinbekommen.

Da xsane2sandwich unter Trusty bei mir zumindest ziemlich lausige Ergebnisse liefert (keine Ahnung, was da wieder schiefläuft...) habe ich noch eine Version, sozusagen "xsane2OCRmyPDF", zusammengebastelt, mit der man PDFs mit Textlagen direkt aus XSane heraus erstellen kann. Das geht natürlich nur unter Trusty (jedenfalls hab' ich OCRmyPDF unter Precise nicht zum Laufen bekommen).

Passt das besser hier in den Artikel, oder in den bestehenden xsane2sandwich-Artikel, oder soll ich einen eigenen Artikel dafür machen?

so long
hank

Das Link am Beginn des Artikels geht an eine mittlerweile stillgelegte Stelle. Ich habe es durch das (hoffentlich) richtige ersetzt, es dabei aber nicht hinbekommen, daß da nur OCRmyPDF steht und das Link selbst hinter diesem Text verborgen liegt. Es wäre schön, wenn das noch jemand korrigiert.

An der Stelle, an der es um das Entpacken des Archivs geht, bleibt mir etwas unklar (bin halt Anfänger): Soll man etwa alles nach /opt entpacken? Weil man danach noch Symlinks anlegt, scheint mir das ganze doch so gedacht zu sein, daß man für den variablen Teil besser andere Plätze nimmt. Aber welche wären da denn zu empfehlen? Für temporäre Daten vielleicht /tmp?

/opt gehört doch root und es sieht so aus, als ob das Programm dort auch noch Arbeitsverzeichnisse (tmp, ist jhove auch so eins) für Zwischendaten anlegt. Geht das Programm dann überhaupt? Oder muß man dann vor alles unnötig sudo setzen?

passer domesticus

passer-domesticus schrieb:

Das Link am Beginn des Artikels geht an eine mittlerweile stillgelegte Stelle. Ich habe es durch das (hoffentlich) richtige ersetzt, es dabei aber nicht hinbekommen, daß da nur OCRmyPDF steht und das Link selbst hinter diesem Text verborgen liegt. Es wäre schön, wenn das noch jemand korrigiert.

erledigt.

An der Stelle, an der es um das Entpacken des Archivs geht, bleibt mir etwas unklar (bin halt Anfänger): Soll man etwa alles nach /opt entpacken? Weil man danach noch Symlinks anlegt, scheint mir das ganze doch so gedacht zu sein, daß man für den variablen Teil besser andere Plätze nimmt. Aber welche wären da denn zu empfehlen? Für temporäre Daten vielleicht /tmp?

/opt gehört doch root und es sieht so aus, als ob das Programm dort auch noch Arbeitsverzeichnisse (tmp, ist jhove auch so eins) für Zwischendaten anlegt. Geht das Programm dann überhaupt? Oder muß man dann vor alles unnötig sudo setzen?

Gute Frage... /opt hat halt den Vorteil, dass auf Mehrbenutzersystemen keine mehrfache Installation erfolgen muss. Ansonsten wuerde ich bei reinen Desktop-Systemen mit einem einzigen Nutzer immer empfehlen, innerhalb des eigenen Homeverzeichnisses zu agieren, um der Rechteproblematik aus dem Weg zu gehen.