Umlaute falsch bei copy/paste

[Martin Τrautmann]

Hallo,

gibt es bekannte Probleme und Lösungen bei copy/paste von Texten mit
Umlauten?

Ich habe hier immer wieder mal PDFs, wo die Umlaute patzen.

Beispiele:
AnschlÄsse statt Anschlüsse
ÇuÖere statt äußere
BlÅcke statt Blöcke

Im Text wird alles richtig angezeigt. Aber schon die Suche nach dem Wort
funktioniert nicht.

Von daher funktioniert auch kein pdftotext (aus dem xpdf-Paket), egal ob
mit -enc Latin1 oder -enc UTF-8

Was im PDF drin steht weiss ich nicht - es ist PDF 1.7, text als stream

/Creator (vspdflib \(www.visagesoft.com\))

Es findet sich z.B.
/Encoding /MacRomanEncoding

... allerdings arbeite ich hier auf dem Mac und sollte dann eigentlich
eher weniger Probleme damit haben.

Schönen Gruß
Martin

[Martin Τrautmann]

Post by Martin Τrautmann
Ich habe hier immer wieder mal PDFs, wo die Umlaute patzen.
AnschlÄsse statt Anschlüsse
ÇuÖere statt äußere
BlÅcke statt Blöcke
Im Text wird alles richtig angezeigt. Aber schon die Suche nach dem Wort
funktioniert nicht.
Von daher funktioniert auch kein pdftotext (aus dem xpdf-Paket), egal ob
mit -enc Latin1 oder -enc UTF-8

Nachtrag: pdffonts sagt mir

name type emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
VSAFBG+TimesNewRomanPSMT TrueType yes yes no 26 0
VSAFBD+Arial-ItalicMT TrueType yes yes no 17 0
VSAFBF+ArialMT TrueType yes yes yes 23 0
VSAFBC+Arial-BoldMT TrueType yes yes no 14 0
VSAFBJ+SymbolMT TrueType yes yes yes 29 0
VSAFBE+TimesNewRomanPS-BoldMT TrueType yes yes no 20 0

[Christian Zietz]

Post by Martin Τrautmann
gibt es bekannte Probleme und Lösungen bei copy/paste von Texten mit
Umlauten?

Probleme gibt es z.B., wenn ein benutzerdefiniertes Encoding verwendet
wird und keine "Übersetzungstabelle" dazu im PDF hinterlegt ist. Eine
einfache Lösung ist mir in diesem Fall nicht bekannt.

Christian

[tlvp]

Post by Martin Τrautmann
Hallo,
gibt es bekannte Probleme und Lösungen bei copy/paste von Texten mit
Umlauten?
Ich habe hier immer wieder mal PDFs, wo die Umlaute patzen.
AnschlÄsse statt Anschlüsse
ÇuÖere statt äußere
BlÅcke statt Blöcke
Im Text wird alles richtig angezeigt. Aber schon die Suche nach dem Wort
funktioniert nicht.
Von daher funktioniert auch kein pdftotext (aus dem xpdf-Paket), egal ob
mit -enc Latin1 oder -enc UTF-8
Was im PDF drin steht weiss ich nicht - es ist PDF 1.7, text als stream
/Creator (vspdflib \(www.visagesoft.com\))
Es findet sich z.B.
/Encoding /MacRomanEncoding
... allerdings arbeite ich hier auf dem Mac und sollte dann eigentlich
eher weniger Probleme damit haben.
Schönen Gruß
Martin

Sounds to me as if the PDF document was produced using *one* character-encoding
(ISO-8859-1, or Windows-1252, perhaps, for example), and the document being pasted
into is using another (UTF-8, for example, or ISO-8859-2, say).

Cheers, -- tlvp

[Martin Τrautmann]

Post by tlvp
Sounds to me as if the PDF document was produced using *one* character-encoding
(ISO-8859-1, or Windows-1252, perhaps, for example), and the document being pasted
into is using another (UTF-8, for example, or ISO-8859-2, say).

I hope that this would support utf-8 anywhere, converting it locally.
However, I checked in different tools, such as TextWrangler, to open it
as latin1, utf8, macroman.

It is some kind of utf8 since it does take more than 8 bits after
pdftotext conversion, but with a very different code map.

Please do consider the malfunction of the search option, where I may
enter text within the pdf viewer itself. Anything with 7 bit characters
works fine for search, but 8 bit (if latin1) or utf-8 do not.

[Thomas Kaiser]

Post by Martin Τrautmann
Please do consider the malfunction of the search option, where I may
enter text within the pdf viewer itself. Anything with 7 bit characters
works fine for search, but 8 bit (if latin1) or utf-8 do not.

Und? <news:***@mid.individual.net> stimmt trotzdem. "Custom
Encoding", das nicht ausreichend deklariert ist. Solange die Zeichen im
Bereich 1-127 sind (plain ASCII) alles kein Problem, darüber visuell
zwar korrekt darstellbar (irgendeine Glyph-Zeichen-Zuordnung im PDF
vorhanden) aber eben nicht inhaltlich sauber extrahierbar.

Drum sind solche Sachen auch in PDF/A verboten (am Rande erwähnt)

Gruss,

Thomas

[Martin Τrautmann]

Post by Thomas Kaiser

Post by Martin Τrautmann
Please do consider the malfunction of the search option, where I may
enter text within the pdf viewer itself. Anything with 7 bit characters
works fine for search, but 8 bit (if latin1) or utf-8 do not.

Ja, das klingt am logischsten und nachvollziehbarsten als Erklärung.

Post by Thomas Kaiser
Solange die Zeichen im
Bereich 1-127 sind (plain ASCII) alles kein Problem, darüber visuell
zwar korrekt darstellbar (irgendeine Glyph-Zeichen-Zuordnung im PDF
vorhanden) aber eben nicht inhaltlich sauber extrahierbar.
Drum sind solche Sachen auch in PDF/A verboten (am Rande erwähnt)

Sehr sinnvoll. Warum macht man solche Schweinereien? Die paar Bits mehr
dürften nicht wirklich wehtun.

Ich unterstelle eher mal Dummheit als Böswilligkeit.

Schönen Gruß
Martin

[Michael Unger]

[...] "Custom
Encoding", das nicht ausreichend deklariert ist. Solange die Zeichen im
Bereich 1-127 sind (plain ASCII) alles kein Problem, darüber visuell
zwar korrekt darstellbar (irgendeine Glyph-Zeichen-Zuordnung im PDF
vorhanden) aber eben nicht inhaltlich sauber extrahierbar.

Mal "dumm" nachgefragt: Was passiert, wenn man (in PostScript) nicht

| (text) show

benutzt, sondern stattdessen

| /t /e /x /t glyphshow

natürlich mit anderen Zeichen oberhalb von \177, also 127 dezimal?
Bettelt man da um Ärger, obwohl der Distiller das eigentlich problemlos
"fressen" müsste?

[...]

Michael