staging.inyokaproject.org

Es geht um das xsane2OCRmyPDF-Skript.
Ich habe erfolglos versucht es unter 16.04 (UbuntuMate) zum Laufen zu bringen. Dabei sind mir ein paar Dinge aufgefallen:

1. tiff2pdf is part of libtiff-tools

2. OCRmyPDF, https://github.com/fritz-hh/OCRmyPDF –> "repository is no longer maintained", moved to https://github.com/jbarlow83/OCRmyPDF

3. Kann das unter 14.04 verwendete OCRmyPDF auch für 16.04 verwendet werden?

1. und 2. müssten im Skript also angepasst werden.

Fehlermeldung im xsane2OCRmyPDF.log:

~~~+++~~~~+++~~~
/media/ramdisk/Test0002.pdf started
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
mv: Aufruf von stat für '/media/ramdisk/Test0002.new.pdf' nicht möglich: Datei oder Verzeichnis nicht gefunden
/media/ramdisk/Test0002.pdf ocred using OCRmyPDF
~~~+++~~~~+++~~~Fr 15 Jul 2016 10:59:38 CEST

Auffällig (für mich):

• xsane ist auf einen neueren Stand (nun 0.999, vorher 0.998)

• convert ist neuer (und zeigt teilweise anderes Verhalten, siehe z.B. auch *klick*

Hast Du @Heinrich Schwietering das unter 16.04 bereits zum Laufen bekommen?

Hi!

Das xsane2OCRmyPDF-Skript funktioniert auch unter 16.04, ich hatte bisher nur noch nicht die Zeit und Muse, das zu überprüfen.

Zu deinen Anmerkungen: Das Paket libtiff-tools ist im Text des Artikels erwähnt, im Skript selbst geht es allerdings weniger um die Pakete (das ist Ubuntu-spezifisch) als um die verwendete Software. Den Link zur PDFmyOCR- Seite kann ich da ändern, die aktuelle Version liefert zudem noch einige neue Funktionen (wie z.B. die -s-Option, um Seiten mit bestehender Textlage zu überspringen, sehr praktisch, und wesentlich schneller, als mit -f alles neu machen zu lassen).

Zu deinem Problem:

• Funktioniert OCRmyPDF bei dir außerhalb des Skriptes, also als Komandozeilenversion? Wenn ja, wird es auch unter XSane funktionieren, ob Version 0.998 oder 0.999 ist da meinen Erfahrungen nach unerheblich (habe unter 14.04 auch schon mit 0.999 gearbeitet, ohne dass Probleme mit den Skripten auftraten).

• die Warnung kann getrost ignoriert werden, die bekomme ich auch, aber solange kein "Error" auftritt, kann man das vernachlässigen. Ich weiß auch nicht, wo die herkommt, kann ggf. von convert herrühren, müsste ich aber erst genauer checken.

• Ob die OCRmyPDF Version, die du unter 14.04 verwendet hast, unter 16.04 läuft, kann ich nicht beurteilen, das müsstest du auf der Kommandozeile austesten; ich habe mir eine neue erstellt, weil ich inzwischen auf einem neuen Rechner arbeite (siehe auch oben).

"Beliebter" Fehler: Doppelte Leerstellen in der Konfigurationszeile in XSane, da reagieren alle xsane2xxx-Skripte äußerst anfällig. Ist aber wohl durch die die Art und Weise, wie XSane die Angaben ausliest, bedingt.

Noch dies: Hast du auf deiner "RAM"-Disk Schreibrechte?

so long
hank

Hi!

@ passer-domesticus Habe leider deinen Post vom Anfang des Jahres verpasst; falls noch aktuell, hier ein paar Hinweise.

passer-domesticus schrieb:

Leider habe ich es nicht hinbekommen, mit den Beschreibungen dieses Artikels und des anderen von https://wiki.ubuntuusers.de/OCRmyPDF/ die OCR in xsane zu integrieren. Insbesondere bleibt mir scheleierhaft, wie man die Skripte xsane2sandwich.sh und xsane2OCRmyPDF.sh von xsane aus zugänglich macht. Ich sehe zwar ein grünes Symbol in der Taskleiste, zwischendurch entsteht auch eine *.tiff-Datei meiner Scans. Die pdf-Datei am Schluß ist aber nicht durchsuchbar.

Die Anweisungen für die Skripte werden in der XSane-Konfiguration zu zur Texterkennung gemacht: XSane → Reiter "Einstellungen" → Konfiguration → Texterkennung. Dort den Pfad zum verwendeten Skript angeben, und die gewünschten Option dahinter stellen. Achte darauf, dass keine doppelten Leerzeichen stehen! Liefert die Log-Datei (standardmäßig bin /tmp/xsaneOCRmyPDF.log) irgendwelche Anhaltspunkte?

Es wäre an der Zeit, aus beiden Artikeln einen zu machen

Möglich, aber nicht unbedingt nötig. OCRmyPDF ist zunächst mal eine Kommandozeilenanwendung, die ich im Skript dann für XSane nutzbar gemacht habe.

und einen dritten zu dem hier in der Diskussion angesprochenen Thema "Volltextsuche".

Das ist allerdings ein ganz anderes Thema...

Was ich gerne hätte:

• Aus xsane beliebig viele Seiten nacheinander einscannen, ohne zuvor gezählt zu haben, wieviele Blätter es sind, dabei einmal für alle folgenden Blätter einstellen, welche Bereiche der Vorlage in den Scan gehen sollen (notfalls zwischendurch noch mal durch den Vorschauscan gehen, so daß die geänderten Einstellungen dann für alle dann folgenden Seiten gelten),

• das Ergebnis in eine durchsuchbare PDF-Datei speichern

• und am liebsten nachher noch einen Durchlauf, in dem mir die Stellen in den Bilddateien gezeigt werden, an denen die OCR-Erkennung schlecht ging, um das Erkennungesergebnis manuell korrigieren zu können.

Leider momentan wohl nicht alles gleichzeitig möglich. Du könntest zunächst mit XSane ohne die xsane2xxx-Skripte eine mehrseitige PDF-Datei erstellen (da kannst du auch alle Seiten vorm Abspeichern noch mal ansehen, und ggf. die Reihenfolge ändern), und die dann mit OCRmyPDF mit Textlagen versehen (ginge auch mit dem Skript in XSANE, wenn du die letzte Seite damit anhängst).

Textkorrekturen an PDFs mit OCR sind unter Linux nur sehr aufwändig möglich; in gscan2pdf geht das zwar, allerdings eben nur sehr mühsam.

In der Windows-Welt können das verschiedene Programme, nach meiner Erfahrung recht gut Abbyy Fine Reader. Dummerweise habe ich es nicht hinbekommen, die Version 9.0 davon, die ich habe, mit Wine unter Linux ans Laufen zu bekommen. Es wäre natürlich schöner, mit freier Software eine anständige OCR-Erkennung von PDF-Dateien hinzubekommen, damit man deren Inhalte mit Volltextsuche findet.

Unter Linux kenne ich keine Open-Source-Software, die das alles so hinbekommt. Scan-Programme unter Wine kannst du so weit ich weiß nicht einsetzen, da klappt der Zugriff auf den Scanner nicht. Es gibt "ABBYY CLI OCR for Linux" (http://www.ocr4linux.com/en:start) 🇬🇧, allerdings IMHO recht teuer, was das vielleicht kann.

Ansonsten (Stichwort Volltextsuche) gibt es Paperwork, ich weiß allerdings nicht, ob daraus inzwischen direkt PDF-Dateien erstellt werden können; in der Diskussion war es zumindest.

so long
hank

Nur eine kurze Rückfrage:

Die Texterkennung arbeitet generell zuverlässiger und die Dateien sind bei gleicher Qualität wesentlich kleiner als im PDF-Format.

PDF steht ja schon für Portable Document Format, also ist das Format doppelt. Wird im Wiki trotzdem PDF-Format statt nur PDF verwendet?

Ich hab's jetzt einfach mal in "kleiner als im PDF (Portable Document Format)" geändert, ist ja nicht in Stein gemeißelt, für den Fall, dass es einen anderen Standard gibt.

Hi!

Das xsane2sandwich-Skript liefert in meinen Versuchen fast nur noch unbrauchbare Ergebnisse, da die Textlagen nicht passen, und eigentlich immer viel zu große bounding-Boxes erstellt werden. Außerdem ist pdftk für/ab 18.04 nicht in den Quellen. Ich denke, es wäre sinnvoller, den ganzen Artikel nur noch auf xsane2ocrmypdf auszurichten und ihn ggf. auch umzubenennen - mit Umleitung für xsane2sandwich für eventuelle Verweise aus dem Forum. Das Skript würde ich dann für die PDF-Dateien auf ghostscript oder pdfunite aus den poppler-utils umschreiben, dann kann auf pdftk auch verzichtet werden.

OK?

so long
hank

Hi!

Hab mir das mal in die Baustelle geschoben, um den Guten Vorsatz aus dem letzten Post jetzt umzusetzen...

so long
hank

Hi!

OK. ging schneller als erwartet... Jetzt unter xsane2OCRmyPDF im Wiki.

so long
hank