synOCR synOCR - GUI für OCRmyPDF

[Yippie]

Du hast die Variablen offensichtlich selbst dupliziert. Check mal in der GUI deine globale Umbenennungssyntax. Wenn du immer das Datum vorm Namen willst, kannst du es in der Regel weglassen.
Der Tagname ergänzt ja die globals Umbenennung, aber ersetzt sie nicht.


Das stimmt insoweit, dass vorher keine Variablen im Tagnamen möglich waren.

Ich musste aber im GUI bisher irgendwas mit §tag angeben, damit der tagname aus der yaml-Datei überhaupt angewendet wurde.

 

[geimist]

Hier das Changelog der Version 1.3.
Ich denke, du wirst die Regel entsprechend angepasst haben. Vor der Version 1.3 würde der Dateiname in deiner aktuellen Einstellung sonst so lauten: 2023-02-20§yocr4-§mocr-§docr Renteninformation, mit der Umbenennungssyntax in der GUI (§yocr-§mocr-§docr_§tag).

Kannst du mir mal bitte ein Log mit diesem Verhalten hochladen?

 

[Yippie]

Ok, kann ich machen, aber nicht mehr heute Rechner ist schon aus...

Einen hab ich aber noch, die GUI Optionen :

 

[Yippie]

Hat mir jetzt keine Ruhe gelassen. Ich glaube jetzt weiß ich woher das Datum vor dem erwarteten Tags kommt:

search by tag rule: "LV_1" ➜
                  ➜ condition:        all
                  ➜ tag:              §yocr4-§mocr-§docr Lebensversicherung
                  ➜ destination:      /Lebensversicherung/
                          >>> Rule is not satisfied

                search by tag rule: "FALLBACK" ➜
                  ➜ condition:        all
                  ➜ tag:              §yocr4-§mocr-§docr
                  ➜ destination:      /
                          >>> Rule is satisfied

                search by tag rule: "CITES_1" ➜
                  ➜ condition:        all
                  ➜ tag:              Cites DE-DEG§tagname_RegEx
                  ➜ destination:      /Cites/
                  ➜ RegEx for tag:    [[:digit:]]{6}-[[:digit:]]{2,}
                          >>> Rule is not satisfied

                search by tag rule: "BKK_BONUS" ➜
                  ➜ condition:        all
                  ➜ tag:              §yocr4-§mocr-§docr BKK Erstattung
                  ➜ destination:      /BKK/
                          >>> Rule is not satisfied

                rename tag is: "§yocr4-§mocr-§docr§yocr4-§mocr-§docr Renteninformation"

Von der FALLBACK Rule! Macht aber alles irgendwie keinen Sinn, dann warum wird diese Regel nicht als eigene angewendet, sondern mit einer weiteren kombiniert?

Da war es wieder, mein altes Problem und Wunsch (zumindest als Option): Wenn eine Regel zutrifft, sollten die anderen nicht mehr greifen.

Ich kann die Fallback Regel schon entfernen, damit mein aktuelles Problem gelöst wird, aber wie mache ich es am besten, wenn keine der anderen Rules zutreffen, mindestens als Dateiname ein im Text erkanntes Datum verwendet wird?

 

[DeeKay1]

Den Fall, dass Dokumente getrennt werden sollen, welche bereits auf einem Blatt Papier (Vor- und Rückseite) gescannt werden, hatte ich gar nicht als Eventualität betrachtet (weil in der Regel zusammengehörend).
Man ist ja auch nicht an das Trennblatt fixiert, sondern muss lediglich den gewünschten Begriff wählen. So könntest du einen Begriff wählen, der auf jedem Blatt vorhanden ist (evtl. der Begriff Seite) und definieren, dass Trennblätter erhalten bleiben sollen (was es in der separierten Form aber derzeit nicht gibt - das müsste ich einbauen).

Warum ein doppelseitiges Trennblatt für dich ein Workaround sein kann, ist mir fraglich. Meiner Meinung nach dürfte da etwas an meiner Logik nicht stimmen. Die Funktion findet sich hier, falls jemandem etwas auffallen sollte:
https://git.geimist.eu/geimist/synOCR/src/tag/v1.3.1/APP/ui/synOCR.sh#L1808


synOCR realisiert das direkt in Python (siehe voriger Link).
Hintergrund ist: ich möchte die Dokumente nicht zweimal an OCRmyPDF schicken.
Könntest du das mal etwas näher erleutern?

Sorry, ich hab mich scheinbar falsch ausgedrückt. Fangen wir am besten nochmal bei 0 an
Sollte die Trennseite auch funktionieren wenn man doppelseitige Dokumente damit nutzt?
Folgendes Verhalten hab ich aktuell:
Versicherer A schickt mir ein beidseitig bedrucktes Dokument und Versicherer B schickt mir ein beidseitig bedrucktes Dokument. Ich nehme beide Dokumente, packe die Trennseite dazwischen und sag meinem Scanner: bitte beidseitig scannen.
Variante 1: die Trennseite ist nur auf der Vorderseite mit der Vorlage bedruckt -> nach dem synOCR durchlauf hat das PDF von Versicherer B als erste Seite die leere Rückseite vom Trennblatt.
Variante 2: die Trennseite ist beidseitig mit der Vorlage bedruckt. Dann erfolgt die Trennung wie erwartet. Während des synOCR durchlaufs wird aber eine komplett leere PDF Datei im Default-Ausgabeordner abgelegt. Ich denke das liegt daran das die trennfunktion nicht damit klar kommt das 2 mal direkt hintereinander eine Trennseite in der Eingangs-PDF vorkommt.

 

[geimist]

Ich glaube jetzt weiß ich woher das Datum vor dem erwarteten Tags kommt:

Das war meine nächste Vermutung.
Ja, ich weiß. Die Regelprioritäten … die wurden noch nicht vergessen.
Warum setzt du die Variablen für das Datum nicht global in der GUI, wenn es immer davor sein soll?

 

[geimist]

Ah, ok. Falsch verstanden.

Variante 1: die Trennseite ist nur auf der Vorderseite mit der Vorlage bedruckt -> nach dem synOCR durchlauf hat das PDF von Versicherer B als erste Seite die leere Rückseite vom Trennblatt.

Das ist nur konsequent.
Mein Scanner (Brother ADS2600W) filtert zuverlässig leere Seiten aus, weshalb es bei mir auch nicht zu diesen Problem kommt. Eine alternative Leerseitenerkennung gibt es derzeit noch nicht (in synOCR). Das ist auch gar nicht so trivial, weil man nicht nur auf Text prüfen kann, sondern ggf. auch die Deckung inkl. Schwellwert auswerten muss.

Variante 2: die Trennseite ist beidseitig mit der Vorlage bedruckt. Dann erfolgt die Trennung wie erwartet. Während des synOCR durchlaufs wird aber eine komplett leere PDF Datei im Default-Ausgabeordner abgelegt. Ich denke das liegt daran das die trennfunktion nicht damit klar kommt das 2 mal direkt hintereinander eine Trennseite in der Eingangs-PDF vorkommt.

Interessant.
Dass muss ich mir mal angucken und ggf. an der Logik dahinter feilen.

Danke für das Feedback!

 

[DeeKay1]

Ggf. hilft das: Beim, durch das doppelseitige Trennblatt, leer generierten Dokument ist scheinbar endPage < als startPage (der mittlere Part unten).
Ich hab noch nicht im Detail in den Code gekuckt, rein logisch ergibt das aber schon mal wenig Sinn. Vielleicht reicht das schon als einfacher check um den Aufruf von split_pages zu skippen.

 

[Yippie]

Von der FALLBACK Rule! Macht aber alles irgendwie keinen Sinn, dann warum wird diese Regel nicht als eigene angewendet, sondern mit einer weiteren kombiniert?

Da war es wieder, mein altes Problem und Wunsch (zumindest als Option): Wenn eine Regel zutrifft, sollten die anderen nicht mehr greifen.

Das Entfernen meiner "FALLBACK"-Regel normalisierte das Verhalten wieder: synOCR verhält sich nun wieder wie auch mit der 1.3.0 Version. Ich habe offenbar zwischen dem letzten OCR-Lauf und dem Update auf 1.3.1 noch eine weitere Regel (FALLBACK) eingebaut, die das ungewollte Verhalten erklärt.

Nur, ich versteh' nach wie vor nicht, warum tagname von zwei Regeln gemerged wird. Es ist definitiv so, dass diese beiden Regeln, weil sie konkret auf das aktuelle Dokument zutreffen, diese Zieldateien erzeugen.

RIESTER_3:
    tagname: "§yocr4-§mocr-§docr Renteninformation"
    tagname_RegEx:
    targetfolder: "/Riester/"
    condition: all
    subrules:
    - searchstring: "Renteninformation"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: true
    
AAAA_FALLBACK:
   tagname: "§yocr4-§mocr-§docr"
   tagname_RegEx:
   targetfolder: "/"
   condition: all  
   subrules:  
   - searchstring: ".*"
     searchtyp: is
     isRegEx: true
     source: content
     casesensitive: true

Dummerweise wird dabei nicht nur der Dateiname zerhacktstückt, nein, es werden zudem auch gleich noch zwei Dateien in unterschiedlichen Verzeichnissen erstellt. Deren Zielordner aus den beiden angewendeten Regeln besteht, siehe Bild unten.
Es wird tagname "§yocr4-§mocr-§doc" vor den tagname "§yocr4-§mocr-§docr Renteninformation" gestellt:


Zum Thema Regelprioritäten: Ich habe im Changelog gelesen, dass die Regeln jetzt auch alphabetisch abgearbeitet werden. Dies stimmt soweit, allerdings nicht, wie erwartet, von A -> Z sondern von Z -> A.

Hab's gerade nochmal geprüft. Meine Fallback-Regel wurde bisher, aufgrund des Namens und dem Anfangsbuchstaben "F", zwischen allen anderen Regeln ausgeführt.
Nach dem Umbenennen in "ZZZZ_FALBACK" nahm ich an, dass diese am Schluss bearbeitet wird, wurde sie aber nicht, sondern als erste Regel überhaupt. Nach dem Umbenennen in "AAAA_FALLBACK" erfolgte die Ausführung am Ende aller Regeln.

Irgendwie unlogisch, aber gut, wenn man's weiß auch kein Problem.

Nichtsdestotrotz, wäre in der YAML-Datei, bei jeder Regel, ein Schlüsselwort sinnvoll, welches quasi eine erfüllte Regel als final erklärt und keine weiteren Regeln mehr ausführt (stop) oder die Erkennung fortführt (continue)

Sowas in der Art: behavior: [continue|stop]

RIESTER_3:
    tagname: "§yocr4-§mocr-§docr Renteninformation"
    tagname_RegEx:
    targetfolder: "/Riester/"
    condition: all
    behavior: [continue|stop]
    subrules:
    - searchstring: "Renteninformation"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: true

 

[DeeKay1]

Ggf. hilft das: Beim, durch das doppelseitige Trennblatt, leer generierten Dokument ist scheinbar endPage < als startPage (der mittlere Part unten).
Ich hab noch nicht im Detail in den Code gekuckt, rein logisch ergibt das aber schon mal wenig Sinn. Vielleicht reicht das schon als einfacher check um den Aufruf von split_pages zu skippen.

Ein

if (( "$startPage" <= "$endPage" )); then

in Zeile https://git.geimist.eu/geimist/synO...48ea58c28b4c45f3c60400/APP/ui/synOCR.sh#L1996 scheint das Problem tatsächlich zu lösen.

 

[Yippie]

Idee gesucht, passend zu meinem Posting oben:

Wie gehe ich am besten vor, dass wenn keine meiner Regeln in der YAML-Datei zutreffen, ich am Ende trotzdem eine Dateierhalten, die nicht bloß ".pdf" lautet, sondern mindestens ein Datum, wie "2023-03-05.pdf"?

Dies wäre mein Versuch mit der FALLBACK-Regel gewesen, aber dazu müsste diese Regel als letzte ausgeführt werden, gut, das bekomme ich hin, aber nicht gleichzeitig mit eine weiteren Regel, weil die FALLBACK-Regel zu diesem Zweck sehr allgemein gehalten wurde und damit quasi immer angewendet wird.

 

[Yippie]

Sieh dir das Log mal genauer an. Es war schon immer so das im gesamten Dokument sämtliche Regel angewendet werden und alle gefundenen Tags dann den Dateinamen bilden.

Hm, das mag sein, wie schon geschrieben, habe ich wohl meine Fallback-Regel irgendwann Mal ergänzt aber dann dessen Auswirkung nicht mehr überprüft.

Ob diese Art der Verarbeitung sinnvoll ist, steht auf einem anderen Blatt

 

[DeeKay1]

Nur, ich versteh' nach wie vor nicht, warum tagname von zwei Regeln gemerged wird. Es ist definitiv so, dass diese beiden Regeln, weil sie konkret auf das aktuelle Dokument zutreffen, diese Zieldateien erzeugen.

Sieh dir das Log mal genauer an. Es war schon immer so das im gesamten Dokument sämtliche Regel angewendet werden und alle gefundenen Tags dann den Dateinamen bilden. Das Verhalten nutze ich seit Jahren aktiv und bewusst.

Zum Thema Regelprioritäten: Ich habe im Changelog gelesen, dass die Regeln jetzt auch alphabetisch abgearbeitet werden. Dies stimmt soweit, allerdings nicht, wie erwartet, von A -> Z sondern von Z -> A.

Komisch, das kann ich nicht bestätigen. Bei mir ist es definitiv A -> Z.

 

[DeeKay1]

Ob diese Art der Verarbeitung sinnvoll ist, steht auf einem anderen Blatt

Natürlich ist das sinnvoll. Wie soll man denn sonst komplexe Regelwerke im Sinne von Tags aufbauen? Bei mir mergen zum Teil 10 Tags aus 10 Regeln in den Dateinamen. Das ist der Sinn eines Tagging-Systems: Tag-Regeln vergeben und sämtliche dadurch gefundenen Tags werden auf das Ziel angewendet.

Wie gehe ich am besten vor, dass wenn keine meiner Regeln in der YAML-Datei zutreffen, ich am Ende trotzdem eine Dateierhalten, die nicht bloß ".pdf" lautet, sondern mindestens ein Datum, wie "2023-03-05.pdf"?

Du beschreibst hier bereits das Standardverhalten von synOCR wenn du, wie bereits von @geimist beschrieben, die Datumsangaben über die globale Option setzen lässt. Werden keine Tags gefunden, sieht dein Dateiname nachher so aus: 2023-03-04_OCR.pdf
Mein Regelwerk dazu:

 

[Yippie]

Das Datum ist zwar immer Teil meiner Dateinamen, jedoch ist der Rest des Namens immer individuell. Genauso wie die Einordnung in unterschiedliche Verzeichnisse. Von daher mehrere Regel und mein Plan, ein Tag pro Regel und damit ein individueller Dateiname.

Somit, denke ich, ist die Verwendung der GUI-Option in meinem Fall nicht sehr sinnvoll, denn damit habe ich ja sehr statische Dateinamen, die immer nach demselben Schema aufgebaut sind, so wie bei dir oben. Das hatte ich, als ich synOCR das erste Mal nutze, so eingerichtet, hat sich jedoch als wenig flexibel erwiesen und daher bin ich auf die YAML Konfiguration ausgewichen.

Dass mehrere Tags auf ein Objekt angewendet werden, so wie in manch anderen Programmen, mag ja sinnvoll und wünschenswert sein, und funktioniert ja auch bei mir zu 99.9% wie gewünscht, nur eben für den speziellen Fall eine Fallback Regel aufzusetzen, nicht wie erwartet und dann dummerweise nicht mit allen anderen Regeln im Zusammenspiel.

Gut, ich könnte mir denken in meiner Fallback-Regel sämtliche Bedingungen, die in allen anderen Regeln als Positiv-Bedingung stehen, in der Fallback-Regel dann als Ausschluss-Kriterium angeben. Das würde jedoch erhöhten Pflegeaufwand bedeuten, denn ich müsste jedes Mal, wenn ich eine neue Regel hinzufüge, auch die Fallback-Regel erweitern.

So wie unten mit condition: none und einem RegEx, dies funktioniert perfekt, aber die Regel wird irgendwann Mal ein Monster...

AAAA_FALLBACK:
    tagname: "§yocr4-§mocr-§docr"
    tagname_RegEx:
    targetfolder: "/"
    condition: none
    subrules:  
    - searchstring: "(Wohngebäudeversicherung|BKK Faber-Castell|Versicherungsnehmer|Bonusprogramm|Renteninformation|Versicherungsnummer|Versicherungsschein|Lebensversicherung|EUROPEAN UNION)"
      searchtyp: is
      isRegEx: true
      source: content
      casesensitive: true

 

[DeeKay1]

Ist es wirklich so schlimm wenn das Datum bei den Dateinamen immer an erster Stelle steht? Der Rest bleibt ja dynamisch über die Tags konfigurierbar. Statisch wäre dabei nur, dass das Datum als erstes kommt und danch deine Tags.

 

[geimist]

Nur, ich versteh' nach wie vor nicht, warum tagname von zwei Regeln gemerged wird.

Wie @DeeKay1 schon schrieb: Weil beliebig viele Regeln zutreffen können, um einen Dateinamen aufbauen zu können und nicht nur eine. Du hast zwei Regeln definiert, die beide erfüllt werden.

Dass mehrere Tags auf ein Objekt angewendet werden, so wie in manch anderen Programmen, mag ja sinnvoll und wünschenswert sein, und funktioniert ja auch bei mir zu 99.9% wie gewünscht, nur eben für den speziellen Fall eine Fallback Regel aufzusetzen, nicht wie erwartet und dann dummerweise nicht mit allen anderen Regeln im Zusammenspiel.

Du könntest dir mit einem zweiten Profil abhelfen, welches das Zielverzeichnis des 1. Profils einliest (wo ja nur die Dateien liegen bleiben, die nicht mit einer Regel matchen) und dafür dann lediglich die eine Fallbackregel definieren.

Sowas in der Art: behavior: [continue|stop]

Das wäre ja noch relativ einfach, aber das sollte etwas weitergesponnen werden, indem man Regeln auch mit AND OR NOR ect. verknüpfen kann. Dazu muss die Implementierung auch abwärtskompatibel zu den bisherigen Regeln sein. Ich bin für konkrete Design-Vorschläge (YAML) immer offen.

Ich habe im Changelog gelesen, dass die Regeln jetzt auch alphabetisch abgearbeitet werden. Dies stimmt soweit, allerdings nicht, wie erwartet, von A -> Z sondern von Z -> A.

Das Resultat im Dateinamen sollte A ➜ Z sein. Die Abarbeitung erfolgt intern aber in der Tat Z ➜ A und der Dateiname (bzw. das Tagarray) wird von hinten nach vorn aufgebaut. Das müsste ich für die Regelpriosisierung intern auch umstellen.

Ein

if (( "$startPage" <= "$endPage" )); then

in Zeile https://git.geimist.eu/geimist/synO...48ea58c28b4c45f3c60400/APP/ui/synOCR.sh#L1996 scheint das Problem tatsächlich zu lösen.

Ganz prima - da brauche ich ja gar nicht mehr zu suchen. Ich werde das mal mit in die Beta aufnehmen. Vielen Dank!

---

Ich hoffe, ich hab jetzt nichts vergessen zu beantworten.

 

[geimist]

Ein

if (( "$startPage" <= "$endPage" )); then

in Zeile https://git.geimist.eu/geimist/synO...48ea58c28b4c45f3c60400/APP/ui/synOCR.sh#L1996 scheint das Problem tatsächlich zu lösen.

Ich musste das noch mit der Variable splitpagehandling kombinieren, aber so scheint es zu funktionieren. Vielen Dank nochmal.

Die Beta DSM6 | DSM7 wurde aktualisiert.

 

[DeeKay1]

Gerne. Ist schön auch ab und an mal was zu diesem großartigen Projekt beizutragen. SynOCR erspart mir eine Menge Arbeit
Andere Frage: Kann es sein das die Datumerkennung bei "1. Treffer im Dokument" angepasst wurde und nun nicht mehr das erste Datum, sondern das früheste nimmt?

Das searchfile sieht wie unten aus (für Forum gekürzt). Dennoch bekommt die Datei das Datum 19.07.2022 verpasst, obwohl "1. Treffer im Dokument" ausgewählt ist.

8 Traunstein, den 23.08.22

Bu Sehr geehrte Damen und Herren,

 Rechnungsdatum
19.07.2022

 

[chrortmann]

Hallo zusammen,

ich versuche gerade die ersten Schritte mit synOCR, um meine Gahaltsabrechnungen zu archivieren. Dabei stoße ich auch das Problem, dass der Parser mit der Montats/Jahresangabe im obersten Teil nicht klar kommt und statt dessen mein Eintrittsdatum in die Firma verwendet wird im späteren Dateinamen.

Wir bekommt man denn das hier sauber geparst?
Gibt es da Möglichkeiten?

Mir geht es primär am Ende um eine PDF-File Umbenennung entsprechend Monat/Jahr.