Beiträge von r3z5

Hi,

es ist meiner Meinung nach ein Programmfehler. Ich habe mir mal den Quellcode näher angeschaut. Ich vermute, das die Entwicklung sehr ubuntu nah ist. Die Meldung

Zitat

Bitte installiere das tesseract-Paket 'tesseract-ocr-deu' und starte...

wird im Coding zusammengebaut. Lediglich der Zusatz "deu" wird von der Laufzeit ermittelt. Unter ubuntu gibt es das Paket auch:

ubuntudesktop:~$ apt show tesseract-ocr-deu
Package: tesseract-ocr-deu
Version: 1:4.0.0+git39-6572757-1ppa1~bionic1
Status: install ok installed
....

Eigentlich müsste man die Meldung unabhängig vom Paketanbieter präsentieren.

Warum kommt es zur Fehlermeldung?

Gscan2Pdf versucht die installierten Tesseractpakete zu ermitteln und prüft das mit der Lokalisierung. Was dann zu solchen Hinweisen kommt, die man bei Dir unter opensuse sieht.

Dazu wird folgender Befehl abgesetzt und das Ergebnis in ein internes array gespeichert.

ubuntudesktop:~$ tesseract --list-langs
List of available languages (3):
deu
eng
osd

Die Logik schneidet dabei "List of avaiable..." weg. Übrig bleibt dann

deu, eng, osd.

Unter opensuse sieht das Ergebnis des Befehls aber so aus:

opensuse > tesseract --list-langs
[DS] Profile read from file (tesseract_opencl_profile_devices.dat).
[DS] Device[1] 0:(null) score is 0.482032
[DS] Selected Device[1]: "(null)" (Native)
Warning: Parameter not found: enable_new_segsearch
List of available languages (3):
deu
deu_frak
eng

Mit diesen zusätzlichen Ausgaben kommt die Logik nicht klar und steigt vermutlich aus. Der eigentlich vorhandene Eintrag "deu" wird nicht mehr gefunden.

Eigentlich müsste diese Stelle robuster gestaltet werden und jede Ausgabezeile gegen die "harte" white list mit gültigen Werten geprüft werden oder die Zusätze anders unterdrücken.

Das existiert auch noch in der frischen Version 2.12.1 (lib/Gscan2pdf/Tesseract.pm, sub languages, ff.).

Warum sieht die Ausgabe hier anders aus? Ich vermute, dass die Opensusepakete mit dem Zusatz --enable-opencl gebaut wurden?

Ich sehe auch gerade dass es einen recht frischen Bugreport dazu gibt:

https://sourceforge.net/p/gscan2pdf/bugs/386/

Sogar mit einem Korrekturvorschlag. Wenn ich das bei mir einbaue klappt es nun unter opensuse.

Am besten mal warten..

Zitat

elektronischen Archivierung meiner Post. Und das scheint mit gscan2pdf zu funktionieren.

ja ich auch. Dann macht Texterkennung schon sinn. So kannst Du später mit einer Volltextsuche (z.b Recoll) nach Texten im Dokument suchen.

Unabhängig von der Sinnhaftigkeit kann man im Fehlerdialog unten rechts ankreuzen, ob man einen Fehler zukünftig unterdrücken möchte.

Im Scandialog kann man auch die Texterkennungsengine einstellen (tessract oder GOCR). Hier kann man das auch deaktivieren. Ggf. hilft einer der Punkte, um den Dialog weg zu bekommen.

Zitat von Alero

DVD’s sind inzwischen auf dem Status einer Audio -und Videokassette angekommen. Steinzeittechnik, um die sich nur noch einige wenige eingefleischte Technikenthusiasten bemühen.

ja stimmt. Wobei DVD's noch offiziell verkauft werden. Daher kommt vermutlich auch diese Anfrage, eine DVD so zu rippen, dass der Film dann über kodi oder ähnliches zeitgemäß bzw. "pre-cloud gemäß" konsumiert werden kann. Wäre auf jeden Fall mein erster Schritt gewesen, wenn noch ein Laufwerk hätte.

Hi SuseRookie,

ich benutze gscan2pdf produktiv (nicht unter opensuse). Bei Gscan2pdf ist auch selbst noch viel Bewegung drin. Das Projekt ist aktiv. Siehe:

https://launchpad.net/~jeffreyratcliffe/+archive/ubuntu/ppa

Unter ubuntu läuft das bei mir auch ohne Probleme.

Das Programm greift auf andere (Perl) Komponenten zurück, die teilweise scheinbar nicht weiter entwickelt werden.

Das muss aber nicht heißen, dass es ein Problem ist. Warum es unter opensuse so holpert, kann ich nicht beurteilen, hängt primär aber nicht mit den Programm/darunter liegenden Komponenten zusammen.

Kannst Du PDF, Bildedateien speichern?

Wenn es nur ein Problem mit tesseract gibt, bist du schon nahe dran.

Benötigst Du überhaupt Texterkennung?

Ansonsten kommt an gscan2pdf vom Funktionsumfang nur gimagerreader ran. Die anderen hier vorgeschlagenen können entweder scannen oder bieten ocr-Erkennung aber nicht alles in einem.

Zu K9Copy "Im Juli 2011 wurde bekanntgegeben, dass keinerlei Weiterentwicklung mehr stattfindet."

10 Jahre sind eine lange Zeit in der Softwareentwicklung. Ansonsten kann ich leider nichts betragen, weil ich neulich festgestellt habe (nachdem ich mir seit langer Zeit mal eine DVD günstig gekauft hatte), dass ich gar kein DVD-Laufwerk mehr besitze. Feels bad..

Hi,

hast du das Paket perl-GooCanvas2 installiert?

Ggf. kommst Du dann weiter. Vermutlich werden dann noch Folgeprobleme kommen, falls gscan2pdf hoch kommen sollte.
Ich habe unter opensuse (tumbleweed) gscan2pdf zwar zum laufen bekommen. Scannen geht aber ich kann nichts speichern und die Texterkennung fliegt mir um die Ohren. Es ist also nicht benutzbar.

Bei mir hängt es angeblich fehlenden Abhängigkeit zu libtiff zusammen (trotz installierten Paket) . Es stimmt auch grundsätzlich etwas nicht mit tessr-act Umgebungsvariablen im Zusammenspiel mit gscan2pdf.

Aber ggf. hast Du unter 15.2 mehr Erfolg. *shakka*

Ansonsten geht auch noch gImageReader. Es ist zwar nicht so intuitiv (find ich) aber hier klappt es aber mit Scannen, Texterkennung und Speichern unter opensuse.

Der Umstand, dass gImageReader läuft, lässt vermuten, dass da auch irgendwas bei gscan2pdf selbst nicht sauber implementiert ist. Aber ich spekuliere nur.

Schönen Restfeiertag.

Hi,

mal noch ein Denkanstoß in eine komplett andere Richtung. Ggf. kommt auch ein älteres/schlechteres Kabel mit der Auflösung vom neuen Laptop nicht klar.

Zitat von www.welches-hdmi-kabel.de

Ob ein neues HDMI Kabel notwendig ist, hängt von mehreren Faktoren ab. Der 4K-Übertragungsstandard wird in Theorie bereits seit vielen Jahren für HDMI Kabel aller Art unterstützt (Stichwort: Highspeed). Allerdings kann es immer mal sein, dass die Kabel nicht in der Lage ist, die hohen Auflösungen zu übertragen.

Zitat von HP Tuxedo

Für externe 4K-Monitore über HDMI verwenden Sie bitte hochwertige HDMI-Kabel der Spezifikation mind. HDMI 2.1.

Hi,

kann es ein btrfs-spezifisches "Problem" sein, wie hier beschrieben:

https://www.slicewise.net/debi…ollen-btrfs-dateisystems/

Evtl. fehlt hier ein balancing?

Ansonsten schließe ich mich den anderen Meinungen an, das System nach der Datensicherung, neu aufzusetzen, am Besten ohne btrfs (->ext4).

ok, danke für die Erklärung. Nur um das noch mal sacken zu lassen. Was passiert bei:

LANG=fr_FR.UTF-8 sort -nk 1,1 zz.txt

bzw.

LANG=fr_FR.UTF-8 ls -l /usr/bin/ | LANG=fr_FR.UTF-8 sort --debug -nrk 5 | head -n 60

und

LANG=fr_FR.UTF-8 ls -l /usr/bin/ | LANG=fr_FR.UTF-8 sort --debug -nrk 5,5 | head -n 60

Der erste und letzte Befehl sollte ja klappen oder? Hier würde dann sort das Ende richtig erkennen (Leerzeichen)? Und somit kommen dann keine Leerzeichen mehr im Key vor, die vom fr-locale als Zahl interpretiert werden? Koerrekt?

Wenn das was beim locale ist, müsste das Paket glibc-locale sein oder? Sollte man da nicht mal den Paketbetreuer anfixen?

> rpm -qif /usr/lib/locale/fr_FR.utf8/
Name        : glibc-locale
Version     : 2.32
Release     : 4.1
Architecture: x86_64
Install Date: Fr 25 Dez 2020 21:50:17 CET
Group       : System/Libraries

Steckt hier jemand noch tiefer in der Materie drin?

Hi,

ich konnte nicht raus lesen, ob das bei euch unter Tumbleweed (coreutils 8.32, Release : 6.1) mit fr_FR.UTF-8 geklappt hat oder auch noch ein Problem gab. Bei mir liefen hier alle Versuche sauber.

Zitat

Ich habe aber keine Ahnung, wie man ein locale reparieren kann...

Ich vermute, das da ist was mit sort nicht in Ordnung ist (in Verbindung mit einzelnen locales, bzw. Sonderzeichen). Wenn es in tumbleweed sauber läuft, wurde das schon gefixt (siehe https://lists.gnu.org/archive/…ils/2020-08/msg00019.html ?).

Um das heraus zu finden, könnte man auch unter Leap 15.2 eine neuere Version von core utils einspielen. Es existieren Community-Versionen von 8.32. Ob man das einfach machen darf und das eine gute Idee ist kann ich aber nicht beurteilen. Da fehlt mir das wissen.