synOCR synOCR - GUI für OCRmyPDF

[geimist]

Nein, diese Spalte ist einfach tot. Ich hatte die vorher für Pushbullet genutzt, was ja rausgefolgen ist und durch Apprise ersetzt wurde. In deinem Fall wird die Spalte halt nicht ersetzt, sondern eine neue hinzugefügt. Das hat für die Zukunft keine Relevanz. Die Codebasis soll grundsätzlich in DSM6 und DSM7 gleich arbeiten.

 

[Ghost108]

Ich hab inzwischen das Releasefile ausgetauscht und der Bugfix ist offiziell. Du kannst problemlos aktualisieren. Es macht aber wahrscheinlich auch keinen Unterschied, da deine DB ja schon aktuell ist. (Wenn die DB bereits auf v9 gesetzt ist, wird sie auch nicht aktualisiert.)


Welches DSM?
Kannst du mir mal bitte ein komplettes Log hochladen?

Die Datei?

 

[geimist]

Du legst doch in jedem Profil (in der GUI) fest, wo die Logs gespeichert werden. Bei jedem Programmlauf wird dann ein Log in den festgelegten Ordner erstellt, welches Datum und Uhrzeit im Dateinnamen hat.

Das Loglevel darf nicht auf 0 stehen.

 

[Ghost108]

tjaaa, da ist das Problem. Loglevel 0
was brauchst du denn? Level 1 oder 2?

 

[geimist]

1 sollte für den Normalfall genügen.

 

[Ghost108]

konnte den Fall jetzt leider nicht reproduzieren.
Lasse das Loglevel jetzt so und werde beobachten

 

[geimist]

Versuch es mal mit demselben Dokument von vorhin. Vielleicht ist es auch ein Fehler von OCRmyPDF.

 

[Ghost108]

habe exakt das selbe Dokument verwendet. Lief alles problemlos durch.

 

[geimist]

synOCR fühlt sich jetzt durch das Logging beobachtet und ist brav

PS: Aber hast du auch mal ins Log geguckt?

 

[Ghost108]

ja, da sah alles gut aus. keine erros o.ä.
Habe auch die o.g. Fehlermeldung per Mail nicht erhalten.

 

[DeeKay1]

Kleine Anmerkung zur Python-Datumssuche.
Folgendes Verhalten:
2023-09-30 23:10:50,334 - Line from File: GERMANY 92342 September 13, 2023
2023-09-30 23:10:50,383 - Found date 02.09.2013

Zwischen 92342 und September hat die Originaldatei ganz viele Leerzeichen, die bei der Suche aufgrund der "Leerzeichen entfernen"-Option natürlich weg sind.

Prinzipiell zwei Vorschläge:
- Vorschlag 1: Die Leerzeichen-Entfernung nur für die normale Regex-Suche verwenden, nicht aber für die Datums-Suche.
- Vorschlag 2: Sofern die erste Zahl ein Teil eines viel größeren Worts ist (= nicht durch Leerzeichen getrennt), sollte diese nicht für die Datumserkennung herangezogen werden. In dem Fall gehört die 2 ja zur PLZ 92342.

Persönlich fände ich Vorschlag 2 besser, falls machbar.
Wie seht ihr das?

 

[Gthorsten]

Ich schaue mir das mal an, aber das wird ja demnächst geändert, da gibt der User dann Formate vor. Da kann man das dann mit einbauen

 

[geimist]

Ich bin mir da nicht so sicher, ob ein User definiertes Format hier hilft. Ich denke, Wortgrenzen sollten grundsätzlich berücksichtigt werden, oder?

 

[Gthorsten]

Ja eigentlich schon. Ich schau mir das heute abend mal an

 

[DeeKay1]

Das \b am Anfang sollte den Job tun: \s?\b((([1-9{1}]|0[1-9]|[12][0-9]|3[01])\.?)\s?)(([a-zA-Z]{3}\.)|([a-zA-ZäÄ]{3,12}))\s(\d{4}|\d{2})
Oder das \s? gleich ganz entfernen: \b((([1-9{1}]|0[1-9]|[12][0-9]|3[01])\.?)\s?)(([a-zA-Z]{3}\.)|([a-zA-ZäÄ]{3,12}))\s(\d{4}|\d{2})

Hast du mal über die Nutzung des Python dateutils nachgedacht? Klingt, zumindest in der Theorie, als würde das ganz gut funktionieren.
https://pypi.org/project/python-dateutil/

 

[Gthorsten]

Das hatte ich schon mal in Verwendung. Aber es gab damit Probleme. Muss mal in meiner Doku gucken was damit war.

 

[DeeKay1]

Wäre ja auch zu schön gewesen, wenn das einfach funktionieren würde.

 

[TJ.]

Hallo Zusammen!

Ich stehe mal wieder vor einem für mich größerem Problem. Ich habe regelmäßig Dokumente mit einer laufenden Nummer (siehe Anhang), die ich auslesen und im Dateinamen nutzen möchte. Dabei gibt es auch noch einen größeren Freiraum zwischen LfdNr und der Zahl selbst. Ich finde nun keine Lösung für eine funktionierende yaml-Regel. Das Wiki hat mir auch nicht weitergeholfen. Hat jemand von euch vielleicht eine Idee?

Spoiler: Screenshot

 

[Gthorsten]

Also @DeeKay1 ich habe mir das ganze mal angesehen. Das ganze geht so ohne weiteres nicht, weil dein Format (September 13, 2023) erstmal nicht zu den unterstützen Formaten gehört.
Im Moment werden nur numerische und alphanunerische im Format Tag Monat (ausgeschrieben oder als Abkürzung) und das Jahr unterstützt.
Das was du in deinem beispiel hast, ist ja ein in deutschland nicht übliches Format.
Das soll ja mal kommen, in dem der User über Masken im GUI vorgeben kann, welche Formate er gerne möchte.

Aber zu Zeit geht das soweit erstmal nicht.
Ich kann mir das mal ansehen ob wir das einfach mit hinein bekommen, aber zzt ist es nicht mit vorgesehen.

Die Änderung die du vorgeschlagen hast führt nur dazu, daß kein Datum erkannt wird...

 

[Struppix]

Hallo Zusammen!

Ich stehe mal wieder vor einem für mich größerem Problem. Ich habe regelmäßig Dokumente mit einer laufenden Nummer (siehe Anhang), die ich auslesen und im Dateinamen nutzen möchte. Dabei gibt es auch noch einen größeren Freiraum zwischen LfdNr und der Zahl selbst. Ich finde nun keine Lösung für eine funktionierende yaml-Regel. Das Wiki hat mir auch nicht weitergeholfen. Hat jemand von euch vielleicht eine Idee?

Hallo TJ
das würde in Deinem Beispiel so funktionieren. Leider weiß ich ja nicht, ob die Schreibweise immer analog ist.

rule_1001:
    tagname: Nummer_§tagname_RegEx
    tagname_RegEx: (?i)\b(LfdNr[\ \:]*\K[1-9]*)\b
    condition: all
    subrules:
    - searchstring: (?i)\b(LfdNr[\ \:]*\K[1-9]*)\b
      searchtyp: contains
      casesensitive: false

Gruß Karsten