Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Um mit bscand erstellte PDFs automatisch mit OCRmyPDF umzuwandeln, würde ich gerne inotify verwenden, das den Speicherort überwacht, und bei neu erstellter Datei veranlasst, dass diese weiterverarbeitet wird. Ich versuche gerade, einen Einzeiler aus dem inotify-Artikel dazu entsprechend auszubauen, so sieht er aus: while true; do inotifywait -m -e create --format %w%f /home/heinrich/bscand/ / && ocrmypdf --pdf-renderer hocr %w%f /home/heinrich/bscand/ocrd/%f; done Wenn ich das im Terminal starte, wird mir
Setting up watches.
Watches established.
...(nach Erstellen der Datei)
/home/heinrich/bscand/scan_20190519_191815.pdf
angezeigt, die Überwachung an sich funktioniert also. Allerdings wird die Datei nicht, wie gewünscht, umgewandelt und in einem Unterverzeichnis des Ordners erstellt, angezeigt wird im Terminal sonst gar nichts. Wird die Variable %w/f% nicht weitergegeben? Braucht ocrmypdf ggf. mehr Zeit? Oder muss das ganze doch in ein Skript? so long hank
|
fleet_street
Top-Wikiautor
Anmeldungsdatum: 30. August 2016
Beiträge: 2149
Wohnort: Hunsrück
|
Das erste, was mir aufgefallen ist, dass du zwei Bedingungen für ewigen Lauf hast. Einerseits die while-Schleife und die Opiton -m (--monitor) für inotifywait, welches das gleiche auslöst, wie die Schleife. Nur eines wäre nötig, die Dopplung aber nicht schädlich. Als zweites weiß ich nicht, was "/" (vor dem &&) in dem Kommando soll. Soll das Wurzelverzeichnis auch überwacht werden?
Wird die Variable %w/f% nicht weitergegeben?
Davon gehe ich aus, denn das sind Optionen innerhalb inotifywait und keine globalen Variablen. Ich habe hier das zweite Beispiel aus dem Artikel rausgepickt, weil es die Übergabe in eine Variable beinhaltet, und auf deinen Fall angepasst.
| inotifywait -m -e create --format %w%f /home/heinrich/bscand/ | while read FILE
do
ocrmypdf --pdf-renderer hocr $FILE /home/heinrich/bscand/ocrd/$(basename $FILE)
done
|
Klappt das?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
create ist das Anlegen der Datei, zu dem Zeitpunkt muss die Datei aber noch keinen Inhalt haben (und das Scannen einer Seite dauert ja eine Weile) - ich würde probieren, ob es nicht besser klappt auf ein close(_write) zu warten.
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! @ fleet_street ☺ Vier Augen sehen mehr als zwei: Das "/" in meinem Einzeiler ist schlicht übriggeblieben, als ich mein Verzeichnis in den Befehl gepackt hatte, und ich habe es schlicht nicht gesehen; es sollte nicht das Wurzelverzeichnis o.ä. überwacht werden. Ohne "/" im Befehlsaufruf wird dann auch klar, dass %w%f nicht weitergegeben wird, ocrymypdf meldet dann: %w%f nicht gefunden. Mit deinem Code als kleinem Bashskript funktionierte dann alles wie gewünscht 👍 (naja, ocrmypdf fand erst nicht die richtige pikepdf-Version, weil ich gerade Version 8.3.0 eingespielt hatte, aber noch eine alte pikepdf-Version im Homeverzeichnis dazwischen gefunkt hatte, - aber das hat ja mit inotify etc. nicht zu tun). Besten Dank! Der Hinweis von seahwak1986 wäre sicher berechtigt, wenn der Scan direkt im angegebenen Verzeichnis gespeichert worden wäre, bscand legt aber die für die PDF-Erstellung benötigten .tiff-Dateien erst mal als Temporärdateien ab, die dann erst mit tiff2pdf als PDF erstellt und in das endgültige Verzeichnis gepackt werden, insofern sind sie sofort "ganz" da. Trotzdem Danke fürs Mitdenken! Dann kann ich das ja noch in die bscand-Baustelle aufnehmen. so long hank NACHTRAG: Wie könnte ich denn das Auslösen auf neu hinzukommende .pdf-Dateien beschränken? Es gibt ja Optionen wie --exclude <pattern> , allerdings fehlt mir das Wissen, ein pattern passend auszugestalten... In dem angegebenen Verzeichnis landen ggf. auch "einfache" Scans als .tiff-Dateien, und da passiert, was seahawk1986 vermutet hatte: ocrymypdf versucht, diese Dateien umzuwandeln, was a) nicht erwünscht ist und b) falls es tatsächlich funktionieren würde, erst mit fertig gestellter .tiff-Datei überhaupt sinnvoll wäre. Effekt ist, dass die Scans nicht fertig erstellt werden, bzw nicht abgespeichert... Diese .tiff-Dateien würde ich auch gerne auf png oder jpg reduzieren, weil sie enorm viel Speicherplatz schlucken; ich weiß allerdings nicht, ob das in einem inotify-Skript zusammen mit der PDF-Umwandlung zu bewerkstelligen wäre, oder ob ich die tiffs lieber in ein anderes Verzeichnis packen lasse, und ein weiteres Skript dazu mit convert o.ä. bastel, und darin mit der close_(write) -Anweisung zu arbeiten. Ich versuch mal was ich so hinbekomme...
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Heinrich_Schwietering schrieb: NACHTRAG: Wie könnte ich denn das Auslösen auf neu hinzukommende .pdf-Dateien beschränken? Es gibt ja Optionen wie --exclude <pattern> , allerdings fehlt mir das Wissen, ein pattern passend auszugestalten...
Du willst ja erst mal nur die tiff-Dateien ignorieren - also müsste es '*.tiff' als Pattern tun.
bscand legt aber die für die PDF-Erstellung benötigten .tiff-Dateien erst mal als Temporärdateien ab, die dann erst mit tiff2pdf als PDF erstellt und in das endgültige Verzeichnis gepackt werden, insofern sind sie sofort "ganz" da.
Spricht etwas dagegen den Quellcode von bscand so zu erweitern, dass es eine extra Aktion gibt, die nach dem erstellen der PDF-Datei ocrmypdf aufruft? Dann könnte man auf inotify verzichten und das ganze linear abarbeiten lassen.
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! @ seahawk1986 Danke für das pattern, versuche ich asap! 👍 Die Version mit write_close (Klammern braucht es anscheinend nicht) funktioniert übrigens gut; jetzt werden auch die tiffs in PDFs umgewandelt (wusste gar nicht, dass OCRmyPDF das kann, aber das Programm scheint echt ein Schweizer Offiziersmesser zur PDF-Erstellung und Umformung zu sein 😉 ), allerdinds noch mit der Endung tiff , weil die FILE -Variable die Endung mitnimmt - wie könnt man das ändern? basename scheint ja nur den Pfad zu kassieren, gibt es auch etwas, um die Endung zu kappen? Zum Vorschlag, den Sourcecode zu erweitern: Prinzipiell wäre das die sauberste Lösung, allerdings bin ich da noch nicht tiefer eingestiegen... Eine Verbesserung für das Programm wäre IMHO die Möglichkeit, in der bscand.cgf umfangreichere Angaben zu den Scanoptionen treffen zu können, oder eben andere als im Code eingesetzte Programme zu verwenden. Das übersteigt allerdings meine Kenntnisse doch "etwas"; ich wollte aber sowieso auf der Entwicklerseite ein paar Issues aufmachen. so long hank
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Heinrich_Schwietering schrieb: Die Version mit write_close (Klammern braucht es anscheinend nicht) funktioniert übrigens gut; jetzt werden auch die tiffs in PDFs umgewandelt (wusste gar nicht, dass OCRmyPDF das kann, aber das Programm scheint echt ein Schweizer Offiziersmesser zur PDF-Erstellung und Umformung zu sein 😉 ), allerdinds noch mit der Endung tiff , weil die FILE -Variable die Endung mitnimmt - wie könnt man das ändern? basename scheint ja nur den Pfad zu kassieren, gibt es auch etwas, um die Endung zu kappen?
Man könnte die Endung z.B. so entfernen und durch ".pdf" ersetzen:
| pdf_file="${FILE%.*}.pdf"
|
Zum Vorschlag, den Sourcecode zu erweitern: Prinzipiell wäre das die sauberste Lösung, allerdings bin ich da noch nicht tiefer eingestiegen...
Das sollte nicht allzu schlimm sein, gerade wenn ocrmypdf als Ersatz für tiff2pdf die Erstellung der PDF-Dateien übernehmen kann. Im Anhang ist ein Patch, der das tun sollte (ich habe leider keinen passenden Scanner da, um es auszuprobieren) - um dann ein PDF mit OCR zu erstellen, sollte es genügen für die Action statt "pdf" "pdf_ocr" einzusetzen.
- bscan_ocrmypdf.diff (2.1 KiB)
- Download bscan_ocrmypdf.diff
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12829
|
Ich habe ziemlich sicher schon mal eine Lösung für so eine Aufgabe hier im Forum gepostet. Die müsstest Du noch in der Historie finden.
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! rklm schrieb: Ich habe ziemlich sicher schon mal eine Lösung für so eine Aufgabe hier im Forum gepostet. Die müsstest Du noch in der Historie finden.
Ah ja, dann forsche ich mal in deinen 10014 Beiträgen, wo ich da was Passendes finde 🤣 (btw: wo ist eigentlich dein cooles Avatarbild hingekommen? copyright-Probleme?) Meintest du konkret die Frage nach dem Ändern der Dateiendungen? Dann hätte ich zumindest eine Ahnung/Richtung, wonach ich suchen könnte. Theoretisch hatte ich sowas auch schon bei den ganzen xsane2sonstwas-Skripten; aber das ist inzwischen auch schon mindestens 5-6 Jahre her, dass ich mich damit intensiver beschäftigt habe, und die Grundlagen (z.B. das Ändern der Endung) hab ich wenn ich mich richtig erinnere, auch nicht selbst entworfen, sonder "nur geklaut"... 😉 Aber seahawk1986 hatte das ja schon "erledigt", die Lösung ${FILE%.*}.pdf funktioniert 👍 ! Das --exclude <pattern> musste in eckige Klammern, also --exclude [*.tiff] . damit werden dann tiffs nicht weiterverarbeitet. Aber die Möglichkeit, auch aus regulären Scans-tiifs PDFs zu machen ist auch nicht die schlechteste, im patch ist es ja wohl auch so gelöst. Den teste ich gleich noch; vorab noch die Frage, ob es wohl auch so + // example usage: ocrmypdf --pdf-renderer hocr -l deu input.pdf output.pdf
+ args[0] = "/usr/bin/ocrmypdf";
+ args[1] = "--pdf-renderer hocr";
+ args[2] = "-l deu";
+ args[3] = in_file;
+ args[4] = out_pdf;
+ args[5] = NULL; ginge, ich habe im Eifer des Gefechts die Sprachangabe glatt vergessen... Oder müssten dafür weitere args angelegt werden? --pdf-renderer hocr ist streng genommen eine Option, nicht zwei. Nun, nur Versuch macht kluch... Schon mal besten Dank für den den patch! Sieht, soweit ich das als interessierte Laie beurteilen kann, ganz schlüssig aus! Später mehr dazu. so long hank
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12829
|
Heinrich_Schwietering schrieb:
rklm schrieb: Ich habe ziemlich sicher schon mal eine Lösung für so eine Aufgabe hier im Forum gepostet. Die müsstest Du noch in der Historie finden.
Ah ja, dann forsche ich mal in deinen 10014 Beiträgen, wo ich da was Passendes finde 🤣
Genau. 😛
Meintest du konkret die Frage nach dem Ändern der Dateiendungen?
Nee, ich meinte das Auswerten der Dateisystemereignisse unter Berücksichtigung von Dateinamen, die Sonderzeichen wie Newline usw. enthalten können. Wobei ich sicherlich auch schon mal etwas mit Änderung von Endungen hatte. ☺
Aber seahawk1986 hatte das ja schon "erledigt", die Lösung ${FILE%.*}.pdf funktioniert 👍 !
Genau.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Heinrich_Schwietering schrieb: Aber die Möglichkeit, auch aus regulären Scans-tiifs PDFs zu machen ist auch nicht die schlechteste, im patch ist es ja wohl auch so gelöst. Den teste ich gleich noch; vorab noch die Frage, ob es wohl auch so + // example usage: ocrmypdf --pdf-renderer hocr -l deu input.pdf output.pdf
+ args[0] = "/usr/bin/ocrmypdf";
+ args[1] = "--pdf-renderer hocr";
+ args[2] = "-l deu";
+ args[3] = in_file;
+ args[4] = out_pdf;
+ args[5] = NULL; ginge, ich habe im Eifer des Gefechts die Sprachangabe glatt vergessen... Oder müssten dafür weitere args angelegt werden? --pdf-renderer hocr ist streng genommen eine Option, nicht zwei. Nun, nur Versuch macht kluch...
Es ist eine Option, die in der Schreibweise zwei Argumente erfordert. argparse unterstützt für die Langform auch die Zuweisung mit einnem Istgleichzeichen, also z.B. --pdf-renderer=hocr , dann wäre das ein Argument. Das selbe ist bei -l de vs. --language=de der Fall. Edit: das klappt auch bei der Kurzform, also z.B. -l=de .
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Erfolg! 😎 Der patch funktioniert! Ich musste nur den Ort für meine ocrmypdf-Version korrigieren, liegt in /usr/local/bin. Um die Sprachangabe mit einzubinden, brauchte es zwei weitere args mit -l und deu , die dann natürlich neu durchgezählt werden mussen. der oben versuchte Weg führte nicht zum Erfolg, ggf. wegen der Leerstellen im den args ? Außerdem noch die Fehlerausgabe auf ocrmypdf , damit alles seine Ordnung hat. Die entsprechende Passage in main.c: static int ocr_pdf(const char* in_file, const char* out_pdf)
{
pid_t pid;
const char* args[9];
int ret = -1;
// example usage: ocrmypdf --pdf-renderer hocr -l deu input.pdf output.pdf
args[0] = "/usr/local/bin/ocrmypdf";
args[1] = "--pdf-renderer";
args[2] = "hocr";
args[3] = "-l";
args[4] = "deu";
args[5] = in_file;
args[6] = out_pdf;
args[7] = NULL;
pid = exec_process(args[0], args);
if(pid)
{
ret = wait_process(pid);
if(ret)
fprintf(stderr, "ocrmypdf returned an error %d\n", ret);
} D.h. wenn weitere Optionen verwendet werden sollen, könnten die nach dieser Art eingefügt werden - ocrmypdf bietet ja eine Vielzahl davon 😉 Gaaaaaanz dickes Dankeschön an dich, seahawk1986 ♥ ☺ 😇 ! (Sowas in der Art hatten wir doch schon mal so, siehe scanbuttond (Abschnitt „Mehrfachbelegung-von-Tasten“), oder? Ist auch schon wieder fast vier Jahre her...). Wenn es für dich OK ist, baue ich das noch in den Artikel mit ein; den Patch würde ich dann nochmal mit der -l deu -Variante erstellen. so long hank EDIT: Dann sollte so ja auch der email-Button mit einer entsprechenden action belegt werden können? Allerdings müsste dafür ja erst ein Scan erstellt werden, und in ein "verandfreundlicheres" Format umgeformt werden - pdf wäre ja nicht verkehrt. hmmm... Ich versuche erstmal, wie das per inotifywait funktioniert.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Heinrich_Schwietering schrieb: Wenn es für dich OK ist, baue ich das noch in den Artikel mit ein; den Patch würde ich dann nochmal mit der -l deu -Variante erstellen.
Nur zu, das ist ja das Schöne an freier Software, dass man sie auf die eigenen Bedürfnisse anpassen kann. Heinrich_Schwietering schrieb: EDIT: Dann sollte so ja auch der email-Button mit einer entsprechenden action belegt werden können? Allerdings müsste dafür ja erst ein Scan erstellt werden, und in ein "verandfreundlicheres" Format umgeformt werden - pdf wäre ja nicht verkehrt. hmmm... Ich versuche erstmal, wie das per inotifywait funktioniert.
Wenn bscand in der User-Session läuft, könnte man nach dem Erstellen der PDF-Datei xdg-email nutzen, um das bevorzugte Mailprogramm mit der Datei als Anhang eine neue Nachricht generieren zu lassen. Im Prinzip kann man analog zur Vorgehensweise aus dem Patch beliebig viele zusätzliche Aktionen definieren.
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! seahawk1986 schrieb:
Nur zu, das ist ja das Schöne an freier Software, dass man sie auf die eigenen Bedürfnisse anpassen kann.
OK, Danke!
Wenn bscand in der User-Session läuft, könnte man nach dem Erstellen der PDF-Datei xdg-email nutzen, um das bevorzugte Mailprogramm mit der Datei als Anhang eine neue Nachricht generieren zu lassen. Im Prinzip kann man analog zur Vorgehensweise aus dem Patch beliebig viele zusätzliche Aktionen definieren.
So hatte ich mir das schon gedacht; xdg-email müsste ich mir erst mal genauer anschauen. Solange bscand nicht über irgendwas systemweites systemd-mäßiges gestartet wird, sondern als Autostart-Eintrag, dürfte das ja gehen, mit Programmen, die unter root laufen gabs damit immer Probleme... Mal sehen, ob ich das so hinbekomme. Mit inotifywait geht es zumindest, | #!/bin/bash
inotifywait -m -e close_write --format %w%f /PFAD/ZU/tiffs | while read FILE
do
#wandelt das Bild von tiff zu jpg um
econvert -i $FILE -o /PFAD/ZU/email/$(basename ${FILE%.*}.jpg)
rm -f $FILE
#hier wird Evolution zum Versenden eingesetzt
evolution --display=:0.0 "mailto:?attach=/PFAD/ZU/email/$(basename ${FILE%.*}.jpg)" #öffnet Evolutions Maileditor und fügt das Bild als Anhang an
done
|
Die tiffs landen dabei in einem eigenen Verzeichnis und werden nach dem Konvertieren gelöscht, die jpgs wandern in ein anderes (Unter-)Verzeichnis, von woaus sie dann von Evolution verwendet werden können - ggf. könnte es eleganter sein, aber es erfüllt seinen Zweck... gestartet wird das ganze über die Email-Taste, die die scan-action auslöst. so long hank
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Das Belegen der email-Taste durch das Programm selbst bereitet mir etwas Kopfschmerzen. Ziel ist, die mit bestehenden Funktionen (file-Taste eine tiff-Datei erstellen/etwas daran anhängen, dann per extra-Taste die pdf_ocr-Aktion aufrufen), erstellte PDF dann mit der email-Taste als Anhang einer Mail in Evolution zu öffnen. Allerdings ist mir nicht klar, wie ich für eine neu definierte action email die Anweisung erstelle, dieses Dokument aufzurufen. Anhängen an die Sektion
static int ocr_pdf(const char* in_file, const char* out_pdf)
funktioniert nicht; die dort eingesetzten Argumente beziehen sich anscheinend nur auf ocrmypdf. Wenn ich
case BTN_ACTION_EMAIL:
if(access("/PFAD/ZUR/OCRD-PDF", F_OK) == 0)
... (wobei mir nicht klar ist, wie das dann weitergehen müsste...) erstelle, müsste darin ja - wenn ich richtig liege - dieser Aufruf geregel werden; das Programm müsste prüfen, ob die durch ocrmypdf erstellte PDF existiert etc. Da allerdings hapert es bei mir - ich stelle mir vor, dass es entweder mit einer zusätzlich in /tmp/ abgelegten PDF ohne die Datumserweiterung gehen könnte (wie es ja für die "internen" tiff-Dateien geregelt ist), oder über eine Variable, die den gerade erstellten PDF-Namen und Pfad beinhaltet, die ich dann einer Sektion
static int email(const char* in_file, const char* email)
...
args[0] = "/usr/bin/xdg-email";
args[1] = "--attach";
args[2] = ERSTELLTEPDF;
...
aufrufe.. Ginge das ggf. mit etwas wie #define ERSTELLTEPDF="out_pdf" in der Sektion zu ocrmypdf? Und müsste so eine Definition dann nach Gebrauch wieder aufgehoben werden? Fragen über Fragen... so long hank
|