synOCR synOCR - GUI für OCRmyPDF

[Ghost108]

der witz an der ganzen Sache ist ja:
Wenn ich die Datei wieder zurück von Error Files in den Hauptordner packe und der "zweite Durchlauf" erfolgt, klappt es

 

[nas_stephan]

Moin.
Mal eine Frage als Neunutzer (ich schaue gerade, ob ich synOCR oder paperless-ngx nutzen will):
Nach absolut simpler Installation (Container Manager, dann das spk, dann die Aufgabe mit Skript anlegen) muss ich mir jetzt Gedanken zur Nutzung machen.
Ich kann ja, soweit ich das bisher verstanden habe,
a) einfach nur pdf Dateien durchsuchbar machen, dh. alles im Zielordner kann von entsprechenden anderen Programmen durchsucht werden. Geht das auch aus Windows heraus?
b) zusätzlich über Regeln in der yaml Datei auch Dateien Kategorisieren und in entsprechende Ordner ablegen (kann synOCR auch Ordner erzeugen?).
Für b) muss ich dann ja aber ALLE tags und Kategorien (und Zielordner?) schon im voraus angeben? Das ist ja ein enormer Aufwand, hier alles abzubilden, oder?
In meinem Bankprogramm sind z.B. schon ganz viele (Standard) -Kategorien und -Regeln definiert. Gibt es sowas hier auch?

 

[Yippie]

Ich steh wieder Mal komplett aufm Schlauch mit einer RegEx in der yaml-Datei.

EMAIL:
    tagname: "§yocr4-§mocr-§docr EMail §tagname_RegEx"
    tagname_RegEx: "(?i)(Betre.*: *)\K.*"
    targetfolder: /EMail/
    condition: all
    subrules:
    - searchstring: "m.ok@mail.de"
      searchtyp: contains
      isRegEx: false
      multilineregex: false
      source: content
      casesensitive: false

Das Log gibt mir hier als Fehler(?) aus:


Was genau stört den Interpreter hier? Das \K findet sich auch im Wiki als Beispiel und die doppelten Anführungszeichen benötige ich ja wegen dem : im eigentlichen RegEx.

Welchen RegEx Dialekt verwendet eigentlich synOCR? Nehme an den von Python, oder?

Dann noch eine Frage zum Aufbau einer Such-RegEx: Im PDF, eine gescannte EMail, steht folgendes:

Betreff: Synology NVMe
Von: Hans Otto <m.ok@mail.de>
Datum: 27.12.2022, 21:00
An: Werner Maier <w.m@baendiger.de>

Ich möchte zuverlässig PDFs anhand deren Inhalt erkennen, die bspw. aus einem Mail-Programm wie Thunderbird gedruckt wurden.
Wie müsste nun ein Searchstring aussehen, damit ich bspw. "Betreff:", "Von:", "Datum:" und "An:", verteilt über mehrere Zeilen, erkennen kann?

 

[geimist]

Ich kann ja, soweit ich das bisher verstanden habe,
a) einfach nur pdf Dateien durchsuchbar machen, dh. alles im Zielordner kann von entsprechenden anderen Programmen durchsucht werden. Geht das auch aus Windows heraus?

Da der Textlayer direkt in die Datei geschrieben wird, ist es grundsätzlich unabhängig, welches OS du nutzt.
Wenn der Ausgabeordner aber von Universal Search indiziert wird, so kannst du diesen Index nicht über einen Mount des Netzlaufwerks (= SMB) nutzen, aber z.B. in Drive. Ich nutze im privaten Umfeld eh einen Abgleich des Outputordners mit meinem Client und hier wird kommen die Dateien automatisch in den Indes des OS. Dokumente finde ich dann einfach über die systemweite Suche.

b) zusätzlich über Regeln in der yaml Datei auch Dateien Kategorisieren und in entsprechende Ordner ablegen (kann synOCR auch Ordner erzeugen?).

Ja, regelbasierte Ordner werden automatisch erzeugt.

Für b) muss ich dann ja aber ALLE tags und Kategorien (und Zielordner?) schon im voraus angeben? Das ist ja ein enormer Aufwand, hier alles abzubilden, oder?
In meinem Bankprogramm sind z.B. schon ganz viele (Standard) -Kategorien und -Regeln definiert. Gibt es sowas hier auch?

Nein, eine Vorlage gibt es bisher nicht. Das wäre prinzipiell eine gute Idee, aber die Regeln sind halt sehr granular einstellbar, was wiederum einer globalen Vorlage entgegensteht.

Ich steh wieder Mal komplett aufm Schlauch mit einer RegEx in der yaml-Datei.

Vielleicht kann @Struppix mehr dazu sagen.

Welchen RegEx Dialekt verwendet eigentlich synOCR? Nehme an den von Python, oder?

In Verbindung mit RegEx wird mit Bash grep mit -P (Pearl Syntax) aufgerufen. Nur so ist z.B. lookahead / lookbehind möglich.

 

[Struppix]

Was genau stört den Interpreter hier? Das \K findet sich auch im Wiki als Beispiel und die doppelten Anführungszeichen benötige ich ja wegen dem : im eigentlichen RegEx.

Guten Morgen,
nun die Frage zu beantworten ist aus der Ferne schwer, denn ich habe das Problem mit dem : wie schon erwähnt nicht. Da kann ich auch nur mutmaßen. Das ihn jetzt das \K stört ist schon erstaunlich, wird aber dem Syntax geschuldet sein.
Grundsätzlich gibt es aus meiner Sicht zwei Möglichkeiten. Du maskierst den : in Deiner Regel oder Du "knippst" den Fehler mit dem : endlich mal aus.

Versuche mal folgendes:

(?i)(Betre.*\:)\s*\K.*

oder

(?i)(Betre.*\:\s*)\K.*

was uns dann logischerweise zu dem bringt, da weniger Systembelastung

(?i)(Betre.+?\:)\s+?\K.*

Was machen wir? Wir maskieren den : mit einem \ hier mein Suchstring

dies ist ein test
Betreff : meine Mail
von gestern

Ich möchte zuverlässig PDFs anhand deren Inhalt erkennen, die bspw. aus einem Mail-Programm wie Thunderbird gedruckt wurden.
Wie müsste nun ein Searchstring aussehen, damit ich bspw. "Betreff:", "Von:", "Datum:" und "An:", verteilt über mehrere Zeilen, erkennen kann?

Das mit dem "verteilt über mehrere Zeilen" verstehe ich nicht ganz.

Karsten

 

[nas_stephan]

Ich nutze im privaten Umfeld eh einen Abgleich des Outputordners mit meinem Client und hier wird kommen die Dateien automatisch in den Indes des OS

Was meinst du damit? Ich will ja Dokumente aufs NAS scannen, dort OCRen und ggf. wegsortieren. Ich will die aber nicht dann auch noch wieder auf dem PC haben - höchstens vom PC auf den/die Netzwerkordner zugreifen wo die Dokumente liegen. Und dann wäre eine Suche nach (OCR)Stichworten natürlich hilfreich.

 

[Yippie]

Das mit dem "verteilt über mehrere Zeilen" verstehe ich nicht ganz.

Das mit den alternativen RegEx kann ich leider erst testen, wenn wieder zuhause. Vielen Dank schon Mal!

Mit dem verteilt über mehrere Zeilen, sollte bedeuten, dass in der PDF bspw. immer der Text so wie unten steht:
Ein PDF-Druck aus dem Mail-Programm.

Betreff: Synology NVMe
Von: Hans Otto <m.ok@mail.de>
Datum: 27.12.2022, 21:00
An: Werner Maier <w.m@baendiger.de>

Um eine E-Mail-PDF über entsprechende YAML-Regeln zuverlässig zu erkennen, habe ich mir die Wörter "Betreff, Von, Datum, An" ausgesucht. Diese sollten somit mein(e) Searchstring(s) sein.

Wie man im Beispiel oben sieht, stehen die vier Wörter jetzt aber nicht in einer Zeile, sondern verteilt auf vier Zeilen. Diese gilt es nun zu erkennen.

Aber ich denke ich habe bereits die Lösung zu meinem "Problem", welche ich auch bereits in anderen YAML-Regeln nutze, aber aus irgendwelchen Gründen bei einer E-Mail-PDF nicht draufgekommen bin :
Vier Subrules definieren mit jeweils einem der vier o.g. Wörter.

Zur noch genaueren Erkennung, könnte ich mir noch vorstellen, ein RegEx zu basteln, welches in der An: Zeile zusätzlich noch eine E-Mail-Adresse findet. Gleiche auch für die Zeile mit dem Wort Von:

Denke dies werde ich erstmal so umsetzen...

 

[Struppix]

Vier Subrules definieren mit jeweils einem der vier o.g. Wörter.

So ist es.

Zur noch genaueren Erkennung, könnte ich mir noch vorstellen, ein RegEx zu basteln, welches in der An: Zeile zusätzlich noch eine E-Mail-Adresse findet. Gleiche auch für die Zeile mit dem Wort Von:

Hierzu einfach jeweils eine weitere Subrule hinzu nehmen.

Gruß
Karsten

 

[Yippie]

Servus Stephan!

Ich wollte wieder Mal nachfragen, ob es vielleicht dieses Jahr Pläne gibt, in die YAML-Datei eine Art Stopp-Anweisung einzubauen, welche nach einer erfolgreicher Erkennung/Anwendung einer der definierten Regeln, die noch vorhandenen Regeln ignoriert.

Ich habe leider viel zu oft den Fall, dass zwar eine einzige Regel greifen würden, meine vorh. Fallback-Regel aber sehr oft zusätzlich greift und dadurch Dateinamen entstehen, die nicht brauchbar sind.

Die Fallback-Regel soll sicherstellen, dass wenn keine der anwendbaren Regeln greift, einfach nur der originale Dateiname zurückgegeben wird. Problem ist wohl eher, dass diese Fallback-Regel nicht exakt genug definiert ist bzw. auch gar nicht definierbar ist und somit zusätzlich zur Anwendung kommt.

 

[Gthorsten]

Hallo Yippie,
Ich habe auch schon oft vor diesem Problem gestanden.
Bisher habe ich aber immer irgendwie eine andere Lösung gefunden.
Stephan und ich hatten schon einmal darüber gesprochen, die ganze Regel Auswertung nach python zu verlegen. Weil da einiges einfacher wäre als in der bash.
Leider sind wir da aber noch nie zu einer Lösung gekommen.
Diese Lösung hätte aber größere Änderung zu Folge.
Ich, und ich denke Stephan auch, wissen aber noch nicht wieviel Zeit wir darin investieren können.
Denn es gibt noch andere Punkte auf der Liste,
Und das private hat natürlich immer Vorrang.

Ich werde aber nochmal darüber nachdenken

 

[Struppix]

Die Fallback-Regel soll sicherstellen, dass wenn keine der anwendbaren Regeln greift, einfach nur der originale Dateiname zurückgegeben wird. Problem ist wohl eher, dass diese Fallback-Regel nicht exakt genug definiert ist bzw. auch gar nicht definierbar ist und somit zusätzlich zur Anwendung kommt.

Mal ne ganz dumme Frage. Wieso eigentlich so kompliziert.
1. Den Fallback hat ja Stephan schon drin. Sprich wird keine Regel erfüllt, wird doch der Original Name verwendet. Oder liege ich da falsch?
2. Ansonsten könnte man vlt. einfach nur den Namen des Original Files abfragen, und wenn gleich mit dem neuen Namen macht er X und wenn ungleich macht er Y. Dafür stehen Variablen zur Verfügung, sodass das sogar in einer RegEx gehen sollte. Nur warum denn siehe 1.

Karsten

 

[Yippie]

Meine Fallback Regel ist vom Namen her mit dem Präfix AAAA_ versehen damit diese Regel am Ende zuschlägt,falls alle anderen versagen.
Schon in dieser Fallback-Regel musste ich aber sämtliche Suchbegriffe der anderen Regeln ausschließen. Dies ist erforderlich, da synOCR ja immer alle Regeln anwendet, wenn die Suchbegriffe passen.

Vielleicht als abstraktes Beispiel:

LEBENSVERSICHERUNG
  equal = Suchbegriff: LV-182828
  tagname_RegEx = yyyy-mm-dd Lebensversicherung
RENTE
  equal = Suchbegriff: RV-12344
  tagname_RegEx = yyyy-mm-dd Rentenversicherung
AAAA_Fallback
  not equal = Suchbegriff: LV-182828, RV-12344
  tagname_RegEx  = yyyy-mm-dd

Normales Verhalten: Wenn das Dokument keine Lebensversicherung ist oder nicht von der Rentenversicherung stammt, wird die letzte Regel, den Dateinamen mit dem erkannten Datum ersetzen.

Ist alles schön und gut, aber was ist, wenn kein Datum erkannt wird? Dann würde ich gerne den Dateinamen im Original belassen. Diese letzte Möglichkeit konnte ich bisher noch nicht umsetzen.

Genauso stört mich, dass ich in der Fallback Regel, wenn neue, definierte Regeln, wie Lebensversicherung2, hinzukommen, deren Suchbegriffe auch immer als Ausschluss im Fallback hinzufügen muss.

Mache ich das nicht, dann greift zunächst die erwünschte Regel und mit der Fallback Regel, wird dem bereits korrektem Dateinamen nochmals das Datum vorangestellt.

Könnte ich bspw. in der Regel Lebensversicherung eine Option setzen, dass mit positiver Erkennung, alle weiteren Regeln obsolet sind, dann würde die Fallback Regeln nicht mehr greifen und mir den Dateinamen nicht ein zweites Mal anpassen.

 

[Schrotti]

Moin aus HH,

ich stelle gerade fest, dass bei der Ablage von Scans , diese teilweise in neuen kryptischen Ordnern angelegt werden. Und zwar nicht im Unterordner sondern im Parentordner. Der heißt dann bpsw. V61KRU~W.
Im Log ist mir nur aufgefallen, dass im Target zwischen
Versicherungen und Sozialversicherung ein \ anstelle eines / angegeben wird.

target: /volume1/homes/*****/Dokumente/Karstens Dokumente/synOCR/Scan_out_OCR/Versicherungen\Sozialversicherung/2023-07-05-Meldebescheinigung Sozialversicherung Barbara.pdf

Die YAML dazu:

---

tagname: Meldebescheinigung Sozialversicherung Barbara
targetfolder: Versicherungen\Sozialversicherung
condition: all
subrules:
- searchstring: Meldebescheinigung
searchtyp: contains
isRegEx: false
source: content
casesensitive: true
- searchstring: Sozialversicherung
searchtyp: contains
isRegEx: false
source: content
casesensitive: true
- searchstring: Barbabra
searchtyp: contains
isRegEx: false
source: content
casesensitive: true

 

[Struppix]

ein \ anstelle eines / angegeben wird

Ändere mal in Deiner YAML den \ durch einen /

 

[Schrotti]

Echt jetzt?
Man sieht den Wald vor lauter Bäumen...

 

[Struppix]

Könnte ich bspw. in der Regel Lebensversicherung eine Option setzen, dass mit positiver Erkennung, alle weiteren Regeln obsolet sind, dann würde die Fallback Regeln nicht mehr greifen und mir den Dateinamen nicht ein zweites Mal anpassen.

Nun hatte eben mal Zeit das zu testen.

Aus meiner Sicht gibt es 3 mögliche Wege dahin.
1) Über Regeln, wobei dann ein ähnlicher Wag zu gehen ist wie bei Dir. Doch Du machst es nicht konsequent, mal nur so.
2) Über ein Postscript
3) Über die in synOCR beinhaltete Funktion

Und wie ich bereits schrieb ist die Funktion schon in synOCR drin. Die hatte Stephan extra hinzugenommen. Ich denke das ist aber schon ne ganze Weile so. Müssen wir mal das Änderungs-LOG prüfen.
Einzig Dein AA ist nicht drin.

Hier der ganze Schmarrn zum Download.

Und mal nur am Rande. Der Fallback funktioniert schon, und zwar in mehreren Varianten. Greift bzw. trifft keine Regel zu dann der hier gezeigte. Außerdem wird kein Datum gefunden, nimmt er das aktuelle.


Und zum Schluss die Bilder hierzu

# synOCR_YAMLRULEFILE   # keep this line!


rule_1001:
    tagname: §yocr4_§mocr_§docr_Lebensversicherung
    condition: all
    subrules:
    - searchstring: LV-182828
      searchtyp: contains
      isRegEx: false


rule_1002:
    tagname: §yocr4_§mocr_§docr_Rentenversicherung
    condition: all
    subrules:
    - searchstring: RV-12344
      searchtyp: contains
      isRegEx: false

 

[Yippie]

Danke schon mal, ich werds mir später am Tag mal genauer durchlesen bzw. anwenden

 

[moleribal]

@geimist der Einzeiler per Aufgabenplaner funktioniert soweit gut. Besten Dank dafür!
Habe dem Canon-Support bzgl. der Art die PDF-Datei auf dem Netzlaufwerk zu schreiben geschrieben.

Ich habe nun die Antwort vom Canon Support bzgl. NTLMv1 und dem PDF Thema erhalten:

Vielen Dank für Ihre Anfrage zu Ihrem MAXIFY MB5150.

Leider kann ich von dieser Stelle nur bestätigen, dass das MAXIFY MB5150 das Protokoll NTLMv2 nicht unterstützt. Aktuell kann ich Ihnen dies nur so mitteilen und ich werde Ihren Wunsch nach einem Update der Gerätesoftware an die zuständigen Stellen in unserem Hause weitergeben.

Ob es in Zukunft eine Anpassung der Software geben wird, so dass auch NTLMv2 unterstützt wird, kann ich Ihnen leider nicht sagen.

Auch hinsichtlich Ihrer zweiten Anfrage bezüglich der Arbeitsweise des Gerätes beim PDF-Scannen kann ich Ihnen kein Update in Aussicht stellen, sondern auch in diesem Fall nur Ihre Kritik an die zuständigen Stellen weitergeben.

Ich kann nachvollziehen, dass es für Sie enttäuschend ist, dass unser MB5150 lediglich das Protokoll NTLMv1 unterstützt und dass aus Sicherheitsaspekten die Unterstützung von NTLMv2 wünschenswert ist. Supportseitig können wir jedoch leider nichts an den aktuellen Spezifikationen ändern, sondern nur die Kritik zur Kenntnis nehmen und die zuständigen Stellen informieren, dass Sie eine Änderung hinsichtlich der Unterstützung der NTLM-Protokolle wünschen.

Ich danke Ihnen für Ihr Verständnis.

Leider enttäuschend. Umso mehr der Aufruf an die Community, die ebenfalls das Problem mit Canon Produkten hat, den Support zu kontaktieren. Je mehr Leute sich darüber beschweren, desto höher wird die Priorität dafür bei Canon.

Beste Grüsse
Erich

 

[Monacum]

Leider heute der Klassiker, man ist selbst nicht zuständig, aber gibt es an die zuständigen Leute weiter… Als ob es mich interessieren würde, wer genau in der Firma dafür zuständig ist. Aber danke dir fürs Nachhören und dass du uns hier die Antwort mitgeteilt hast!

 

[mördock]

Puuuhhh, man muss doch immer am Ball bleiben.
Da nutzt man synocr seit Jahren und ist begeistert, dann überlegt man ob man nicht auch Bilder in PDF umwandeln und mit synocr bearbeiten könnte.
Tja, und dann stellt man fest das die installierte Version (1.12) völlig veraltet ist und inzwischen ein völlig neuer Funktionsumfang zur Verfügung steht. Ach ja, und community package hub ist auch down.
Irgendwie peinlich das ich das alles verpasst habe.
Aber irgendwie auch ein Kompliment an synocr und @geimist , das Paket ist wie ein VW Käfer, läuft und läuft und läuft.
Danke für die tolle Arbeit!!!