![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Hat Martin ja auch vor ("[...] Benutzer erweitert Markierung[...] ");
nur halt ziemlich umständlich.
Wolfgang
Weil das nur Einzelbuchstaben aka nur einen Teil der Fälle löst, und
außerdem nicht, wo der einzelne Buchstabe hin gehört; vgl. das gepostete
Beispiel in <d8701c5b-c2c8-5704-19c1-4a51f56523ba@skynet.be>: Wie soll
ein Programm entscheiden, ob das einzelne "d" nun zu dem davor stehenden
"Buchstaben" oder zu dem dahinter stehenden "er" gehört?
Und viele andere Fälle wie "B ericht ü b e r den" oder "G runderw erb"
fallen da auch ganz oder teilweise durch.
Mit so einer Lösung hast du mehr Arbeit damit, dir Fälle und
Kombinationen zu überlegen, und dann noch, welche False Positives dabei
ggf. auftreten könnten. Was ist /technisch/ gesehen der Unterschied
zwischen dem (zweiten) Leerzeichen in "G runderw erb" und dem
Leerzeichen in "sowie die"?
Wolfgang
Hallo zusammen,
Weil das nur Einzelbuchstaben aka nur einen Teil der Fälle löst, und
außerdem nicht, wo der einzelne Buchstabe hin gehört;
Danke Wolfgang für dein Statement.
Wenn's hilft:
Wurde ja schon angeregt, denn Text in Notepad++ zu kopieren. Dort kann man dann zum Beispiel ein Makro aufzeichnen, dass innerhalb einer Markierung mit Suchen an " " und ersetzten durch "" zumindest diese Arbeit schnell abnimmt, mit einem guten Tastaturkürzel versehen geht dass dann flotter als das Cursor positionieren und vor- oder zurücklöschen.
Geht aber natürlich auch in LO mit einem aufgezeichneten Makro, nur sind da die Shortcuts schon deutlich belegter.
Hallo Gerhard,
Ja, das funktioniert.
Dabei habe ich feststellen müssen, dass beim automatischem oder händischem Speichern des Dokumentes das Dialogfenster immer ins Zentrum des Bildschirmes springt. das ist etwas lästig
mit freundlichem Gruss
Martin
Ich verstehe nicht, was an einem umständlichen Makro einfacher sein soll
als simples Suchen-und-Ersetzen. Bei jedem Fund sequentiell entscheiden,
ob es sich dabei um ein reguläres oder überzähliges Leerzeichen handelt,
muss der User in beiden Fällen sowieso manuell.
Wolfgang
Hallo Martin,
bisher habe ich mich nicht in die Diskussion eingeschaltet,
weil ich sicher war,
nichts zur Makro-Programmierung beitragen zu können.
Je länger ich jedoch mitlese,
desto mehr kommt mir die Idee,
dass das Problem ganz anders zu lösen ist:
Ich habe die Vermutung,
dass das verwendete OCR-Programm nicht optimal funktioniert.
Daher mein Angebot:
Wenn Du mir eine gescannte Seite mit mindestens 300 dpi
(z. B. als *.tif, *.jpg, *.png) schickst,
kann ich versuchen,
die Texterkennung mit anderen OCR-Programmen durchzuführen.
Ich habe die Hoffnung, dass das besser funktioniert,
als mit dem Programm, das Du verwendest.
Mit freundlichen Grüßen
Jörn
PS: … aber nicht an die Liste schicken
(die Datei wird nicht weitergeleitet),
sondern direkt an meine Absende-Adresse
Hallo Martin,
ich kopiere mal einen Absatz
"Die Versammlung setzte u. a. den K reisetat fest, nahm den B ericht ü b e r den
G runderw erb der Eisenbahn sowie die B ekäm pfung des V iehw uchers entgegen
und beschäftigte sich (vertagend) m it der F rage der Beschaffung d er durch die
neue K reisordnung nötigen D iensträum e."
Ich schmeiße mal die Idee eines Parser-Makros mit Wörterbuch-Abgleich in den Raum:
* Du hast eine TXT-Datei (ohne Formatierungszeichen etc.) des Buches.
* Du hast ein Wörterbuch als durchsuchbare Datei.
* Das Parser <https://de.wikipedia.org/wiki/Parser>-Makro liest aus
der TXT-Datei ein einzelnes Zeichen und schreibt die Ausgabe wie
folgt in eine Ergebnis.txt:
o Ist es ein Satzzeichen: --> ausgeben wie gelesen, ggf. noch
nachfolgendes Leerzeichen anhängen.
o Ist es eine Ziffer: --> ausgeben wie gelesen, das kann
wahrscheinlich nicht automatisch korrigiert werden.
o Ist es ein Buchstabe: --> in Variable speichern, nicht ausgeben.
+ Weitere Zeichen einlesen und - wenn es kein Leerzeichen ist
- an die Variable anhängen. Ist es ein Leerzeichen, den
Text der Variable im Wörterbuch suchen.
# Wenn vorhanden: --> ausgeben in Ergebnis.txt [aus K
reisetat wird Kreisetat].
# Wenn nicht im Wörterbuch, Leerzeichen ignorieren,
nächstes Zeichen lesen.
* Ist es ein Buchstabe, diesen an die Variable
anhängen. [aus ü b e r wird über] aus [G runderw erb
wird Grunderwerb.
* Ist es eine Ziffer oder ein Satzzeichen, das Wort
aus Variable trotz negativem Wörterbuch-Ergebnis
schreiben.
* Weiter beim übergeordneten _Wenn_. Die Anzahl wird
man begrenzen müssen, falls mehrere Begriffe mit
Blocksatz-Leerzeichen nacheinander nicht im
Wörterbuch sein sollten.
Ich hoffe, die Idee ist damit nachvollziehbar. Der letzte Link ganz unten auf der Wikipedia-Seite <http://www.cis.uni-muenchen.de/~leiss/parsing-06-07/parsingfolien.ps> beschreibt das noch "wissenschaftlich".
Die Programmierung ist durch die notwendigen Fallunterscheidungen mit einigem Aufwand verbunden; ob sich das lohnt, ist sicher vom Umfang des Buches abhängig. Andererseits könnte es so etwas auch schon geben, da ich auch schon solche Typoskripte mit "manuellem Blocksatz" gesehen habe (Nachfrage in München?).
Gruß Michael
Hallo!
Generell ist der Ansatz zum Wörterbuch und txt-Quelldatei schon richtig.
Letztlich ist es "nur" eine Frage des sortierens von Chars, also
Characters. Aber würde ich zu diesem Zweck kein LO verwenden, sondern
ein Programmierprogramm C/C++, Perl ... oder einen sehr guten Editor mit
Macro-Funktion wie UltraEdit. Zudem ist OCR das Problem, da es 1. die
gelesenen Zeichen interpretiert ehe sie ausgegeben werden und 2. in OCR
sämtlich Daten wie Formatierungen hinterlegt werden. Somit scheidet ein
txt aus, da die Formatierungen verloren gehen. Es gleibt also sehr viel
Handarbeit übrig.
Generell kann man sich die Sortierung mittels Schleifen vereinfachen,
wenn man sich folgendes vor Augen führt:
a) die kürzesten Worte haben 2 oder 3 Buchstaben in am auf der die das.....
b) wenn man nach dem vorherigen Chr sucht erleichtert sich die Suche
ungemein.
Letztlich sind es Schleifen:
1. Durchlauf: suche nach mehreren Leerzeichen hintereinander und löschen
bis auf ein Leerzeichen
2. Druchlauf: suche nach Leerzeichen mit nachfolgendem Buchstaben so
lange bis Buchstabe Buchstabe erkannt wird
3. Durchlauf: Suche nach voran gestellten Leerzeichen, prüfen ob
mindestens 2 vorangestellte Zeichen, oder mehr, vohanden sind oder ob
ein Zeichen mit vorangestelltem Leerzeichen erkannt wird.
Man erhält einen sehr guten zusammenhängend lesbaren Text mit wenig
manueller Editierung. Aber die Formatierung geht vollständig verloren
und muss manuell wiederhergestellt werden. Letztlich wäre eine sehr gute
Sekretärin im Abtippen schneller.
Erinnert irgendwie an 3 Schritte vor und zwei zurück.
Grüsse
Hallo Michael,
ein sinnvoller Algorithmus eines jeden Programmes (und somit auch eines Makros) muss eine möglichst niedrige Fehlerquote aufweisen - in der Regel weit unter 1 %! Nur dann macht er Sinn und der Programmieraufwand würde sich lohnen.
Das Problem ist bei OCR Software so alt wie die Mustererkennung selbst - und ein OCR Programm, dass nur 95% korrekt liest ist an sich schon "Schrott". Der Nacharbeitungsaufwand ist einfach zu hoch.
Dein Flussdiagramm geht vom vorhandenen Textteilen aus und findet eine (möglichst) optimale Lösung... das reicht aber nicht!
Nimm den folgenden Satz und lass Deinen Flow drüberlaufen:
" Nach dem H und dem I folgt ein J."
Daraus würde mit Deiner Logik werden:
"nach dem Hund und dem I folgt ein J." - Diesen nun eingebauten Fehler später manuell zu finden ist quasi unmöglich. Das Programm wäre also nutzlos. Je mehr Du aber den Algorithmus verfeinerst und verkomplizierst, um so mehr Ausnahmen werden Dir auffallen. Der Aufwand wäre viel höher, als die manuelle Korrektur. Falls Dir die perfekte Lösung einfällt, kannst Du Dich bei allen OCR-Herstellern bewerben - die nehmen Dich dann mit Kusshand:)
Der richtige Ansatz war in der Diskussion schon angesprochen worden: Die OCR Software. Die muss entweder besser trainiert werden oder sie ist ungeeignet. Das nachträglich zu korrigieren per Software ist m.A. Unsinn.
Findet sich dort keine Lösung, bleibt eigentlich nur die manuelle Korrektur wie schon öfter beschrieben.
VG
Thomas
Hallo!
Entschuldige, aber Du bringst mich gerade zum Schmunzeln und Lachen, weil...
OCR eine Software ist mit der ua Google seit bald 20 Jahren historische
Bücher digitalisiert und erfolgreich archiviert. Und dies mit einem
hervorragenden Ergebnis. Von daher ist Deine Aussage nicht ganz korrekt.
Besser sollte diese lauten: Die Markt befindlichen OCR- Programme kommen
nicht über eine einfache Demo-Version hinaus. Mit anderen Worten: Geht;
ist aber nicht zur Weiterverarbeitung zu gebrauchen.
Richtig schlimm wird es, wenn man versucht Text und Formatierung zu
lösen, den Text seitenweise getrennt zu verarbeiten und dann beides
wieder zusammenzufügen.
Wenn man die Möglichkeit hätte an eine richtig teure OCR-Demo-Version
heran kommen zu können würde es vielleicht klappen. Aber alles unter
2000€ ist so gar nicht brauchbar.
Wie gesagt: Leerzeichen zu löschen geht mit einigem Programmier-Aufwand
und bedarf immer eines Paperbackwriters. Dabei geht die Formatierung
aber definitiv verloren. Ob es sich lohnt steht auf einem anderen Blatt.
Vom Zeitaufwand ist Abtippen schneller.
Als LO-Marco habe ich es nie versucht- unter SO4 ging es defintiv nicht.
Mit Programmierung C/C++/Perl oder UltraEdit geht es -als fortlaufender
Text mit mehr oder minder vielen Kontext-Fehlern.
Grüsse
Guten Morgen an Alle.
ich bitte Euch um Entschuldigung!
Nach der mehrmaligen Anmerkung, das Problem bei der Quelle, dem OCR-Programm, zu lösen, habe ich das OCR in ein anderes Format arbeiten lassen.
ich gehe mal ins Detail:
ich scanne und ocre Bücher für den hiesigen Geschichtsverein
anfangs arbeitete ich mit Tesseract OCR
dann schaffte ich mir den Fujitsu SV600 ScanSnap mit ABBY Finreader for ScanSnap an
anfangs liess ich in Word-Format ocren; dann fragte mich der Vereinspräsident nach durchsuchbaren PDF und da Finereader die auch erzeugen kann, habe ich die PDF erzeugt und dann aus diesen PDF mittels Speichern als TXT den Text zum Überlesen kopiert.
so auch bei dem letzten Buch mit den leerzeichen in den Wörtern
nach euren Bemerkungen habe ich Finereader die Scandatei mal wieder in Word-Format ocren lassen: und da sind keine Leerzeichen in den Wörtern!
Ich bitte euch nochmals um Entschuldigung; und ich hoffe, dass meine Beschreibung anderen helfen mag
mit freundlichem Gruss
Martin jenniges
Hallo Martin,
das Thema, das den Anlass für diesen Mailverkehr bildet, hat sich ja wohl erledigt.
Aber das Verhalten des LibO-Dialogs zum Suchen und Ersetzen nach einem Speichern lässt sich sich sicher nicht durch den Anwender beeinflussen, damit muss man leben.
Gruß
Gerhard
Hallo!
Dies ist auch sicherlich nicht Aufgabe einer Office-Lösung.
Grüsse