ubuntuusers.de

Interessant! Wie wurde die Beispieldatei erstellt? Wenn ich das Ganze durch Tesseract "jage", bekomme ich ein PDF, das neben einer Bilddatei einen mehr oder weniger korrekten Text enthält (siehe Anhang). Also, OCR unter Linux kann den Text durchaus sicher erkennen.

noisefloor schrieb:

@Frieder108: bei mir öffnet sich das PDF auch im Firefox - aber aus dem PDF-Betrachter des Firefox heraus kann man es auch normal speichern.

ja Danke - da stand ich wohl auf dem Schlauch.

Zum Thema - ja, egal mit welchem Programm ich das .pdf öffne, das Ergebnis nach einem "copy+paste" ergibt keinen Sinn und ist unleserlich.

Hmm, da fällt mir spontan nichts dazu ein - so was hatte ich mit eigenen PDFs noch nie. ☹

Das Dokument kommt von meiner Bank ☺ Jetzt habe ich das vorher erwähnte "Master PDF Editor" ebenso ausprobiert - mit den Standard Einstellungen kann der Text ebenfalls nicht durchsucht werden. Also müsste man ebenso eine Texterkennung anwerfen. Es scheint also kein Weg an einer OCR vorbei zu führen. Da ich im Gegensatz dazu unter Windows mit Acrobat keine Fehler im Text habe (was bei einer OCR ja hin und wieder passen kann), scheint da noch ein andere Weg gegangen worden zu sein.

@MrFrank

...Dh also im Umkehrschluss, dass Acrobat mit den veralteten Dateien besser umgehen kann. Frage wäre noch, weshalb?

und

...Da ich im Gegensatz dazu unter Windows mit Acrobat keine Fehler im Text habe (was bei einer OCR ja hin und wieder passen kann), scheint da noch ein andere Weg gegangen worden zu sein.

Die Antworten dazu findet man in der von mir genannten Quelle im Unterpunkt 6.1
Kurzform: Die Adobe eigenen Produkte können selbständig die (in der Version 3) fehlenden Tags setzen.

Einfach mal die einzeln Unterpunkte durchlesen. Da steht, rund um das Thema PDF, viel interessantes Zeugs drin. 😉

Bournless schrieb:

@MrFrank

...Dh also im Umkehrschluss, dass Acrobat mit den veralteten Dateien besser umgehen kann. Frage wäre noch, weshalb?

und

...Da ich im Gegensatz dazu unter Windows mit Acrobat keine Fehler im Text habe (was bei einer OCR ja hin und wieder passen kann), scheint da noch ein andere Weg gegangen worden zu sein.

Die Antworten dazu findet man in der von mir genannten Quelle im Unterpunkt 6.1
Kurzform: Die Adobe eigenen Produkte können selbständig die (in der Version 3) fehlenden Tags setzen.

Einfach mal die einzeln Unterpunkte durchlesen. Da steht, rund um das Thema PDF, viel interessantes Zeugs drin. 😉

Danke Dir, dass ist in der Tat eine sehr gute Quelle!

Es freut mich, dass Dir weitergeholfen werden konnte.

Bitte nicht vergessen, diesen Thread noch als gelöst zu markieren.

Gruß
Bournless

Jep, mache ich!

Noch eine Zusatzinformation: ich habe auch PDFs v1.3, in der das Suchen und copy&paste funktioniert. Dies sind dann wohl Dateien, in denen der Text eingebettet ist.

VG
Frank

Frieder108 schrieb:

noisefloor schrieb:

@Frieder108: bei mir öffnet sich das PDF auch im Firefox - aber aus dem PDF-Betrachter des Firefox heraus kann man es auch normal speichern.

ja Danke - da stand ich wohl auf dem Schlauch.

Zum Thema - ja, egal mit welchem Programm ich das .pdf öffne, das Ergebnis nach einem "copy+paste" ergibt keinen Sinn und ist unleserlich.

Hmm, da fällt mir spontan nichts dazu ein - so was hatte ich mit eigenen PDFs noch nie. ☹

In PDFs kann man allerlei Quark machen, und das Ergebnis sieht im Betrachter immer noch leserlich aus. Meine spontane Theorie waere, dass diese Verunstaltung Absicht ist um Copy & Paste zu verhindern. Ich sehe jedenfalls keinen Fehler in Inyoka oder bei ubuntuusers im Allgemeinen.

sebix schrieb:

In PDFs kann man allerlei Quark machen, und das Ergebnis sieht im Betrachter immer noch leserlich aus. Meine spontane Theorie waere, dass diese Verunstaltung Absicht ist um Copy & Paste zu verhindern.

Dagegen spricht aber, dass unter Windows Copy & Paste einwandfrei funktioniert.

Ich sehe jedenfalls keinen Fehler in Inyoka oder bei ubuntuusers im Allgemeinen.

Das sicher nicht. Aber da könnte schon ein Fehler oder mangelnde Fehlertoleranz in einer Linux-Bibliothek vorliegen. Um einen Bug-Report einzureichen müsste man aber erst einmal wissen, welcher Code verantwortlich ist.

Ich hatte das gleiche Problem mit den neuen Kontoauszügen der Postbank seit Januar 2023 (pdf producer XEP 4.28.759). Ich nutze folgenden workaround: Umwandeln mit pdf2ps nach ps und anschließend wieder zurückwandeln mit ps2pdf nach pdf. Danach geht wieder copy+paste, 'pdfgrep' (zum Durchsuchen) etc.

Anbei mein kleines Skript dazu 'fix_pdf_files.sh':

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#!/bin/sh
# fix corrupted copy & paste from pdf-files (e.g. Postbank Kontoauszug 2023)

fixed_dir="fixed"

mkdir -p "$fixed_dir"
for file in *.pdf
do
  printf "Fixing '%s' in directory '%s'\n" "$file" "$fixed_dir"
  pdf2ps "$file" - | ps2pdf - "$fixed_dir/$file"
done

exit 0

PS: Ich nutze Debian 11, aber das sollte keinen Unterschied machen.