synOCR synOCR - GUI für OCRmyPDF

gaz72 · 05. Sep 2020

Hi Stephan,

ich habe mich gewundert, warum laut Log ein für mich valides Datum (19.06.2008) als invalid deklariert wird und habe mir daraufhin mal den Code angesehen. Kann es sein, dass du in Zeile 914 die Variablen für Tag und Monat in der falschen Reihenfolge übergibst und dass synOCR deshalb das Datum als invalid einstuft, weil es glaubt, die 19 stünde für einen Monat und wegen >12 auf die Nase fällt?

Code:

date "+%d/%m/%Y" -d ${date_mm}/${date_dd}/${date_yy} > /dev/null  2>&1    # valid date? https://stackoverflow.com/questions/18731346/validate-date-format-in-a-shell-script

Dabei ist mir auch noch aufgefallen, dass es im synOCR Ordner eine Datei –time=modify gibt. Kommt die möglicherweise durch Zeile 1009 zustande, weil der Parameter für touch ––time=modify heißen müsste? Das ist allerdings nur eine wilde Vermutung, weil mir da ziemlich sicher das Linux-Talent ausgeht...

Viele Grüße
Guido

geimist · 05. Sep 2020

gaz72 schrieb:
Kann es sein, dass du in Zeile 914 die Variablen für Tag und Monat in der falschen Reihenfolge übergibst …

Diese Funktionsweise hatte mich anfangs auch irritiert, ist aber laut meiner Beobachtung korrekt:

Bash:

admin@DS:~# date "+%d/%m/%Y" -d 06/19/2008 > /dev/null  2>&1 ; echo $?
0
admin@DS:~# date "+%d/%m/%Y" -d 19/06/2008 > /dev/null  2>&1 ; echo $?
1

Ist das Datum korrekt von OCR erkannt worden? (auch kein Leerzeichen dazwischen?)
Du kannst mir gern das komplette Log hochladen. Da gucke ich mir das mal an. Hier der Link: https://geimist.eu/synOCR/_synOCR_userupload.html

gaz72 schrieb:
Dabei ist mir auch noch aufgefallen, dass es im synOCR Ordner eine Datei –time=modify gibt. Kommt die möglicherweise durch Zeile 1009 zustande, weil der Parameter für touch ––time=modify heißen müsste?

Sehr gut beobachtet - vielen Dank. Wird im übernächsten Release gefixt (das aktuelle Release befindet sich in der Freigabe auf cphub.net).

gaz72 · 05. Sep 2020

Ja, du hast Recht, deine Syntax stimmt. Ich habe mir das problematische Dokument nochmal genau angesehen und das Problem liegt woanders. Das Regex für das deutsche Datum schlägt in meinem Dokument auf den String *1501*004535*28.04.17* an, was dann im weiteren Verlauf natürlich korrekterweise nicht als valides Datum erkannt wird.

Was hältst du ersatzweise von dieser leichten Modifikation des Regex?

Code:

^([1-9]|[012][0-9]|3[01])[\./-]([1-9]|[01][0-9])[\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})$

statt

Code:

\y([1-9]|[012][0-9]|3[01])[\./-]([1-9]|[01][0-9])[\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})\y

Nach meinem Verständnis würde das dafür sorgen, dass das Datum frei stehen muss und hat zumindest bei meinem Dokument funktioniert.

Mein anderer Vorschlag mit ––time=modify führt übrigens lediglich dazu, dass eine Datei ––time=modify im synOCR Verzeichnis landet. War also auch kein wirklicher Geniestreich.

Irgendwie nicht mein Tag heute. Sorry für die Verwirrung, die ich gestiftet habe. ?

Viele Grüße
Guido

geimist · 05. Sep 2020

Ich muss mir das mal durchspielen - RegEx sind für mich ein rotes Tuch.
Würde deine Änderung nicht bedeuten, dass das Datum in einer Zeile alleine stehen müsste, um zu matchen (Anfang der Zeile und gleichzeitig Ende der Zeile)?

Edit:
\y wird ja hier als Wortgrenzopterator (awk) genutzt. Deine Sterne scheinen hier fälschlicherweise als Platzhalter interpretiert so dass es fälschlicherweise matcht.

gaz72 schrieb:
Mein anderer Vorschlag mit ––time=modify führt übrigens lediglich dazu, dass eine Datei ––time=modify im synOCR Verzeichnis landet.

War ja definitiv ein Fehler und muss geändert werden

gaz72 · 05. Sep 2020

geimist schrieb:
Würde deine Änderung nicht bedeuten, dass das Datum in einer Zeile alleine stehen müsste, um zu matchen (Anfang der Zeile und gleichzeitig Ende der Zeile)?

Bei meinem Test hat ein Leerzeichen vor und hinter dem Datum gereicht. Ich würde aber auch nicht die Hand dafür ins Feuer legen. Regexe sind für mich auch Hexenwerk. ?

gaz72 · 05. Sep 2020

Hab nochmal nachgelesen. ^ und $ definieren eigentlich laut Doku Beginn und Ende eines Strings. Nur mit Multiline Flag bezeichnen sie Beginn und Ende der Zeile. Sämtliche Online Regex Tester, die ich gerade kurz getestet habe, finden aber mit meiner Regex in vorher 28.04.17 nachher kein Datum, egal wie das Flag steht.

Deine Funktion parseRegex (die ich kein Stück verstehe

) funktioniert aber und findet das Datum solange vorher und nachher ein Leerzeichen steht.

Wie gesagt: Hexenwerk...

ulli_um · 06. Sep 2020

Das /y bzw /b stellt eigentlich sicher das es sich um ein Wort handeln (Leerzeichen vorne/hinten) und nicht zwischendrin (blabla10. 02.2020bla).

^ ist dafür da das man den textanfang bzw $ textende definiert. Das wäre für die datumssuche innerhalb des Textes nicht sinnvoll

geimist · 06. Sep 2020

Danke für deinen Input.
Also ist es nicht gänzlich falsch, wie es jetzt ist. Da sehe ich das falsch positive Ergebnis mit den Sternchen in seinem Match begründet ( *1501*004535*28.04.17* ).
Hast du eine Idee, wie man das vermeiden könnte?

ulli_um · 06. Sep 2020

Hmm ich habs jetzt nicht gestest aber eigentlich dürfte *1501*004535*28.04.17* ohne Leerzeichen nicht als datum erkannt werden mit /y.
Im bash entspricht /y doch /b oder?
Alternativ könnte man hald im regex das Leerzeichen vorne erzwingen

geimist · 06. Sep 2020

Ja, eigentlich schon. Aber es matcht. Ohne Sternchen logischerweise nicht.

Auch nur mit grep funktioniert es nicht wie gewünscht:

Bash:

admin@DS:~$ echo "*1501*004535*28.04.17*" | egrep -o "\b([1-9]|[012][0-9]|3[01])[\./-]([1-9]|[01][0-9])[\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})\b"
28.04.17
admin@DS:~$

schmidi480 · 06. Sep 2020

Hallo geimist,

erst mal vielen Dank für die tolle GUI und das Skript!!! Habe es gestern ausprobiert und gleich ganz viele Tags erstellt. Heute bin ich dann auf ein Problem gestoßen: bei bestimmten Kombinationen meiner Regeln der yml-Datei entsteht für die Variable $renameTag ein String mit exakt einem Leerzeichen, obwohl ich einen leeren String erwartet hätte. Dies führt dazu dass in Zeile 1022 folgendes if greift, statt in die else Bedingung zu springen

Bash:

# Zieldateien verschieben:
    if [ ! -z "$renameCat" ] && [ $moveTaggedFiles = useCatDir ] ; then
        # verwende Einsortierung in Kategorieordner:
        echo "              ? move to category directories"

Das Resultat: Meine Quelldatei wird gelöscht, ohne dass eine Zieldatei geschrieben wird.

Letztlich konnte ich das gewünschte Verhalten erst mal durch das Entfernen der Leerzeichen erreichen:

Bash:

renameCat="$(echo -e "${renameCat}" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')"

geimist · 06. Sep 2020

Hallo schmidi480,

ohne mir jetzt dein Problem näher angesehen zu haben: ich erinnere mich, vor kurzer Zeit an einem ähnlichen Problem gearbeitet zu haben. Kannst du mal gucken, ob es bereits mit der Version 1.0.2 behoben ist (die Version auf meinem Server ist identisch mit der, die auf cphub.net auf Freigabe wartet)?

Wenn nicht, dann würde ich auch gern ergründen, warum die Tag-Variable fälschlicherweise aufgebaut wird. Gib doch bitte mal dein Feedback. Vielen Dank.

schmidi480 · 07. Sep 2020

Tatsächlich? habe es kurz getestet heute Abend und es scheint zu funktionieren. Danke für die schnelle Rückmeldung und den Fix!

ramsesderzweite · 11. Sep 2020

Hi Geimist

Ich habe DSM 7.0 Preview installiert. Mir ist bekannt, dass im Preview noch Limitationen bei Community-Apps bestehen. Wollte dich aber trotzdem fragen, ob du mir einen ungefähren Zeitrahmen nennen kannst, ab dem synOCR auf DSM 7 laufen wird?

Danke dir!

PS: Hier noch der Link zu den Berechtigungsstufen: https://help.synology.com/developer-guide/privilege/preface.html

geimist · 11. Sep 2020

Dazu kann ich dir noch absolut keine Aussage machen.
Ich hatte gestern bereits versucht, die Privilegien zu setzen, was aber nicht von Erfolg gekrönt war. Ich habe noch gar keine Ahnung, welche Änderungen hier nötig werden.

Auch sollen ja die Pakete möglichst nicht als root laufen. Mal sehen, wie zuverlässig das in Verbindung mit Docker realisiert werden kann.

bmidy · 12. Sep 2020

Hallo

Zurest danke fuer diee Super Package !

Woaah

Ich habe ein Problem
Ich moechte nur die Datei mit diese Praefix scannen "ALBA PRO"
und Ich wollte dann dieseerstezen mit "ALBA_PRO"

Also Ich habe der Parameter so eingestellt :

Search pattern source file name : ALBA
Remove Search Pattern
OCR Rename-Syntax: ALBA_§tit

und funktinniert aber nicht ganz genau wie Ich moechte

Also

"ALBA PRO" --> "ALBA_ PRO"

Ich will haben

"ALBA PRO" --> "ALBA_PRO"

Der problem ist wenn Ich definierte es wie folgt:

Search pattern source file name : "ALBA "

oder
Search pattern source file name : "ALBA\ "

oder
Search pattern source file name : ALBA\

es geht nicht

dann Ich kann sehen ein Fehelr in die Logfdiels mit "sed" Befehl

Koenne Sie mir erklarren wie Ich kann defineirte ein "Search pattern source file name" mit ein Leerzeichen am Ende

Danke

geimist · 12. Sep 2020

Herzlich willkommen im Forum, bmidy

Bitte schicke mir ein Log zu.

driftkingisback · 17. Sep 2020

Hallo zusammen, ich habe gestern meine NAS 920+ bekommen
und probiere gerade syn ocr im Docker zu installieren, ist für mich komplettes neuland, ich habe es schon als probiert, auf folgendem Stand bin ich siehe Anhang.
Über eine Hilfe würde ich mich sehr freuen, benutze schon den ix500 ocr , finde das klasse mit der Umbenennung.

Wäre super wenn ihr mir helfen könntet
Gerne könnt ihr mir auch ne PM schicken, dann können wir das über Whats app machen, dann geht es vielleicht schneller, kenne mich da nicht so gut aus

driftkingisback · 17. Sep 2020

das habe ich jetzt auch runtergeladen

geimist · 17. Sep 2020

Hallo @driftkingisback und herzlich willkommen im Forum

zum Installieren, füge die Paketquelle https://cphub.net im Paketzentrum hinzu (Paketzentrum ? Einstellungen ? Paketquellen ? hinzufügen), oder installiere das bereits von dir heruntergeladene spk manuell im Paketzentrum (Vorteil der ersten Methode liegt im Kompfort der Updates)
Installiere Docker (hast du schon erledigt - mehr ist da nicht zu machen)
öffne synOCR und trage deine Einstellungen ein (Pfade, ect.)

Bei weiteren Fragen, einfach fragen …