Dein Wohl hat mir keine Ruhe gelassen
Ich hatte mich bei dieser Variable analog an
tagname_regex
orientiert. Aber ich finde es auch wie von dir gewünscht besser.
Bitte probiere mal hiermit:
synOCR_DSM7_local_BETA.spk
Ok, nun getestet und funktioniert
Bei Verwendung bzw. Angabe des Schlüssels
dirname_RegEx
ohne weitere Verwendung, passiert jetzt mit der Beta-Version wie erwartet nichts.
Weder der finale Dateiname wird beeinflusst, noch wird unnötigerweise ein Verzeichnis erstellt:
YAML:
RULE_001:
tagname: §yocr4-§mocr-§docr Prämie §tagname_RegEx
targetfolder: "Gehalt/"
tagname_RegEx: (?i)(Jahr.*)\s*\K.*((19|20)\d{2})
dirname_RegEx: (?i)(Jahr.*\d{4})
multilineregex: false
condition: all
subrules:
Wird hingegen die Variable
§dirname_RegEx
im Schlüssel
targetfolder
eingesetzt, dann wird entsprechend dem RegEx ein (Unter-)Verzeichnis im Ausgabepfad erstellt, bspw. .\Gehalt\Jahr_2024 und dorthinein die PDF-Datei kopiert.
YAML:
RULE_001:
tagname: §yocr4-§mocr-§docr Prämie §tagname_RegEx
targetfolder: "Gehalt/§dirname_RegEx"
tagname_RegEx: (?i)(Jahr.*)\s*\K.*((19|20)\d{2})
dirname_RegEx: (?i)(Jahr.*\d{4})
multilineregex: false
condition: all
subrules:
Was mich ein wenig stutzig macht ist die Tatsache, dass mein RegEx eigentlich den Text "Jahr 2024" finden sollte, was vom Prinzip auch funktionierte, allerdings hat das dabei erstellte Unterverzeichnis auf einmal einen Unterstrich im Namen, der so nicht im Text existierte:
Jahr_2024.
Im erkannten Text ist (Auszug aus dem Log bzw. der protokollierten .txt Datei): Kein Underscore zwischen Jahr und 2024 vorhanden:
ngen das Jahr 2024 für uns alle
Was kann hier der Grund dafür sein?
Aber zurück zum eigentlichen Test: Funktioniert wunderprächtig - Vielen Dank dafür

Ich und die Gemeinde danken
