synOCR synOCR - GUI für OCRmyPDF

[geimist]

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?

Diese Einstellmöglichkeit gibt es seit der Version 1.3.0 durch die prima Datumsimplementierung von @Gthorsten.

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.

@Gthorsten
Siehst du hierfür eine Möglichkeit, oder ergäbe das zu viel falsch positive Erebnisse?

@chrortmann
Du könntest dir mit einem RegEx behelfen und nicht über die Datumsvariablen gehen. Guck mal HIER.

 

[DeeKay1]

Diese Einstellmöglichkeit gibt es seit der Version 1.3.0 durch die prima Datumsimplementierung von @Gthorsten.

Korrekt. Aber schau nochmal auf mein Beispiel. Ich hab "1. Treffer im Dokument" ausgewählt, es wird aber nicht das erste Datum im Dokument (23.08.22) genommen, sondern das zweite (19.07.2022).

 

[Yippie]

Kann ich diese Option auch direkt in der YAML, per Regel, verwenden? Ab und zu ist dies nämlich ganz hilfreich, statt einer globalen Option, per Regel einzustellen.

 

[Gthorsten]

Diese Einstellmöglichkeit gibt es seit der Version 1.3.0 durch die prima Datumsimplementierung von @Gthorsten.

Anhang anzeigen 80122


@Gthorsten
Siehst du hierfür eine Möglichkeit, oder ergäbe das zu viel falsch positive Erebnisse?

@chrortmann
Du könntest dir mit einem RegEx behelfen und nicht über die Datumsvariablen gehen. Guck mal HIER.

Ich habe ja ein ähnliches Problem gehabt. Habe dann mein eintrittsdatum in die Blacklist genommen.

Das Format Monat /Jahr habe ich erstmal ausgeschlossen, glaube ich(muss mal nachsehen).
Ansonsten können wir gerne versuchen es mal mit hinein zu nehmen.
Keine Ahnung was dann passiert. Ich gucke morgen mal in den Code.
Oder meintest du was anderes?

 

[Gthorsten]

Korrekt. Aber schau nochmal auf mein Beispiel. Ich hab "1. Treffer im Dokument" ausgewählt, es wird aber nicht das erste Datum im Dokument (23.08.22) genommen, sondern das zweite (19.07.2022).

Die Frage ist ja immer was das Skript in der Datei findet. Wenn du magst kannst du mir die Datei ja mal zusenden, also ohne die persönlichen Daten. Dann schaue ich mir das mal an. Oder lade sie bei Stephan hoch. Der leitet die an mich weiter.

 

[geimist]

Korrekt. Aber schau nochmal auf mein Beispiel. Ich hab "1. Treffer im Dokument" ausgewählt, es wird aber nicht das erste Datum im Dokument (23.08.22) genommen, sondern das zweite (19.07.2022).

Ich hab zu flüchtig gelesen - sorry …

Ja, schick mal bitte ein Log oder gar die Datei.

 

[geimist]

Kann ich diese Option auch direkt in der YAML, per Regel, verwenden?

Welche Option meintest du jetzt?

 

[DeeKay1]

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

Ich hab gerade mal noch deine Variante getestet. Bitte noch von "-ge" auf "-g" ändern. Wenn die zu splittenden Dokumente nur eine Seite haben sind startPage und endPage gleich.

 

[DeeKay1]

Die Frage ist ja immer was das Skript in der Datei findet. Wenn du magst kannst du mir die Datei ja mal zusenden, also ohne die persönlichen Daten. Dann schaue ich mir das mal an. Oder lade sie bei Stephan hoch. Der leitet die an mich weiter.

Ungern. Aber ich kann mal versuchen ein paar Testdokumente zu erstellen.
Sofern ich find_dates.py korrekt interpretiere, dürfte es aber an den verwendeten Regex liegen.
Beispiele aus neueren Tests:
- 16. Mai 2022 wird von \s(((0[1-9]|[12][0-9]|3[01])\.?)?)\s(([a-zA-Z]{3}\.?)|([a-zA-ZäÄ]{4,12}))\s(\d{4}|\d{2}) nicht gefunden. Dafür müsste man die Längenbeschränkung hinter [a-zA-ZäÄ] von {4,12} auf {3,12} ändern
- Änliches Spiel für "(Stand 05.04.2022)". Das wird nicht gefunden, da hinter der Jahreszahl eine schließende Klammer ist, die durch den Regex nicht abgedeckt wird

Bezogen auf mein Beispiel ein par Beiträge zuvor, wurde auch 23.08.22 nicht gefunden, da die Jahreszahl 2-stellig ist und nicht 4-stellig.

Es ist spät und ich hab nicht die komplette find_dates.py im Detail durchgearbeitet, aber das sind mal meine ersten findings.

 

[Gthorsten]

Da hast du natürlich recht, der Mai kann so nicht gefunden werden. Wundert mich aber, da ich eigentlich alles im unittest überprüft habe.
2 stellige und 4 stellige Jahreszahlen sollten aber gefunden werden.
Problematisch ist immer nur was dann hinter der Zahl kommt.
Vielleicht habe ich da nicht alles abgedeckt.
Werde mir das nach Feierabend mal ansehen. Auf der Arbeit habe ich leider keinen Zugriff auf den Code und meine Tests.
Also ein wenig Geduld

 

[Yippie]

Welche Option meintest du jetzt?

Die Option "Datum Suchergebnis Reihenfolge", in der ich bspw. den Wert "1. Treffer im Dokument" ausgewählt habe.

 

[geimist]

@Yippie
Nein, das funktioniert nicht über YAML-Regeln. Die Datumsuche ist eine komplett andere Routine, welche bei der Regelabarbeitung bereits abgeschlossen ist.

 

[Foggy]

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.

Anhang anzeigen 80121

Hi!
Mit regex kannst du dir da etwas zusammenbasteln. Z.B.:

Entgeltabrechnung:
    tagname: Entgeltabrechnung §tagname_RegEx
    tagname_RegEx: \d{1,2}+\/\d{4}+
    targetfolder:
    condition: all
    subrules:
    - searchstring: \d{1,2}+\/\d{4}+
      searchtyp: contains
      isRegEx: true
    - searchstring: Entgeltabrechnung
      isRegEx: false

Gruß

 

[Gthorsten]

Ja und nein, es wird dann aber trotzdem das gefundene Datum durch die suchroutine wieder angehängt. Diese Routine läuft ja vor der Regel Abarbeitung

 

[geimist]

Er kann das Ergebnis zwar nicht als Datumsvariable nutzen, aber wenn er diese im Dateinamen weglässt, kann er sich mit dem RegEx behelfen.

 

[Gthorsten]

Stimmt auch wieder

 

[ThomasC]

Hallo!

Ich habe gestern synOCR Version 1.3.1 auf meiner DS216+II installiert.
Nun teste ich gerade die OCR Optionen.
Aktuell gelingt es mir nicht ein PDF als PDF/A-2b Format (--output-type pdfa) inkl. Title (--title TestOCRSYN) zu erzeugen.





Lt. ocrmypdf - Hilfe sollte dies möglich sein.


Frage:
Können aktuell keine weiteren OCR-Optionen an ocrmyPDF übergeben werden oder muss hier auf eine spezielle Syntax geachtet werden?

Viele Grüße
Thomas

 

[DeeKay1]

Aktuell gelingt es mir nicht ein PDF als PDF/A-2b Format (--output-type pdfa) inkl. Title (--title TestOCRSYN) zu erzeugen

Was heißt das konkret? Werden keine Dateien erzeugt? Oder mit dem falschen Format? Was steht denn im Log?
Ich hab den output-type Parameter mit PDF/a selbst im Einsatz und das funktioniert ohne Probleme.

 

[ThomasC]

Es werden Dateien erzeugt, aber im falschen Format und nicht mit dem korrekten Titel.
Das Log sieht wie folgt aus:




Viele Grüße
Thomas

 

[geimist]

Also grundsätzlich werden von OCRmyPDF Dokumente im PDF-A Standard ausgegeben. Leider kommt es bei der Weiterverarbeitung durch die Pythonbibliothek PyPDF2 zu dem Fehler, dass die PDF-A Eigenschaft verloren geht. Dieses Verhalten ist dem Entwickler von PyPDF2 bekannt, wurde aber bisher leider nicht gefixt.

Wenn du darauf verzichten kannst, dass Tags und Autorname in die PDF geschrieben werden sollen, kannst du diesen Schritt mit folgendem Befehl im Terminal oder Aufgabenplaner überspringen lassen (die Änderung muss nach einem Update ggf. wiederholt werden):

/usr/syno/bin/synosetkeyvalue "/usr/syno/synoman/webman/3rdparty/synOCR/synOCR.sh" enablePyMetaData 0