info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PDF und das ü
214 views
Skip to first unread message
HC Ahlmann
Jul 14, 2016, 5:34:51 AM7/14/16
to
Hallo zusammen,
ich bekomme wiederkehrend von einem Auftraggeber PDF-Dateien zur
Bearbeitung, aus denen gelegentlich Textpassagen mit c&p in Editoren,
sei es Word, ein Kommentar im Adobe Reader oder ein webbasiertes CMS
(Pansite), übernommen werden.
Immer wieder gibt es ein Problem mit dem ü und nur dem ü, dass es zu
einem u mit rechts danebenstehenden Punkten wird. Andere Umlaute
zerfallen nicht.
Screenshot des CMS-Editors:
<http://hc-ahlmann.gmxhome.de///temp/ue.tiff>
Screenshot des Word-Editors (Word für Mac 2011, 14.6.6, 160626):
<http://hc-ahlmann.gmxhome.de///temp/ue2.tiff>
Die rote Wellenlinie zeigt einen Rechtschreibfehler an, weil das ü nicht
als solches erkannt wird.
Markiere ich es, verhält es sich wie ein Zeichen, lösche ich es mit
Backspace, sind es zwei Zeichen.
Aber kopiere ich es in TextEdit (1.8, bei 10.8.5 enthalten) als plain
text, ist es ein ü.
Was ist das?
--
Munterbleiben
HC
<http://hc-ahlmann.gmxhome.de/> Bordkassen, Kochen an Bord, Törnberichte
ich bekomme wiederkehrend von einem Auftraggeber PDF-Dateien zur
Bearbeitung, aus denen gelegentlich Textpassagen mit c&p in Editoren,
sei es Word, ein Kommentar im Adobe Reader oder ein webbasiertes CMS
(Pansite), übernommen werden.
Immer wieder gibt es ein Problem mit dem ü und nur dem ü, dass es zu
einem u mit rechts danebenstehenden Punkten wird. Andere Umlaute
zerfallen nicht.
Screenshot des CMS-Editors:
<http://hc-ahlmann.gmxhome.de///temp/ue.tiff>
Screenshot des Word-Editors (Word für Mac 2011, 14.6.6, 160626):
<http://hc-ahlmann.gmxhome.de///temp/ue2.tiff>
Die rote Wellenlinie zeigt einen Rechtschreibfehler an, weil das ü nicht
als solches erkannt wird.
Markiere ich es, verhält es sich wie ein Zeichen, lösche ich es mit
Backspace, sind es zwei Zeichen.
Aber kopiere ich es in TextEdit (1.8, bei 10.8.5 enthalten) als plain
text, ist es ein ü.
Was ist das?
--
Munterbleiben
HC
<http://hc-ahlmann.gmxhome.de/> Bordkassen, Kochen an Bord, Törnberichte
Andre Igler
Jul 14, 2016, 1:39:43 PM7/14/16
to
Am 14.07.16 um 11:34 schrieb HC Ahlmann:
> [ü wird zu u¨, details snipped]
>
> Was ist das?
Codierfehler, grundsätzlich mal.
Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
sich UTF noch immer nicht überall herumgesprochen hat.
So weit ich das durchblickt habe, tritt es vor allem cross-platform auf,
also Win-Texte resp. ISO-latin1 zu meinen Mac, der spricht UTF8.
So oft, dass es mich zu einer tatsächlichen Fehlersuche angeregt hat,
trat es noch nicht auf ...
Wenn Du es raus findest, bitte hier posten :/
addio
¹z.B. von einem Website. Hab' auch schon solche Texte von GitHub
gezogen, nachher mühsam search&replace ...
--
pm <mein vorname> bei <mein nachname> punkt at
—> Mein neues Buch! Jetzt auf www.oluschka.com
www.albinschwarz.com http://weblog.igler.at
> [ü wird zu u¨, details snipped]
>
> Was ist das?
Codierfehler, grundsätzlich mal.
Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
sich UTF noch immer nicht überall herumgesprochen hat.
So weit ich das durchblickt habe, tritt es vor allem cross-platform auf,
also Win-Texte resp. ISO-latin1 zu meinen Mac, der spricht UTF8.
So oft, dass es mich zu einer tatsächlichen Fehlersuche angeregt hat,
trat es noch nicht auf ...
Wenn Du es raus findest, bitte hier posten :/
addio
¹z.B. von einem Website. Hab' auch schon solche Texte von GitHub
gezogen, nachher mühsam search&replace ...
--
pm <mein vorname> bei <mein nachname> punkt at
—> Mein neues Buch! Jetzt auf www.oluschka.com
www.albinschwarz.com http://weblog.igler.at
Andre Igler
Jul 14, 2016, 3:18:59 PM7/14/16
to
Am 14.07.16 um 19:39 schrieb Andre Igler:
> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere,
Ingrid meint, ich sollte das spezifizieren. Also: Ich mache einen Text
auf GitHub in einem Brauser auf, markiere ihn auf dem Schirm und
kopiere/paste ihn anschließend in einen Editor auf meinem Rechner ...
und schwupps werden alle Umlaute zu Doppelzeichen ...
Ähnlich wie bei Dir, dafür bei allen nicht-sieben-bit-ASCII ... warum
das dann bei Dir nur beim ü statt findet ... beats me
Frage: Ist da immer ein *spuck* MS Word dabei, oder geht das auch ganz ohne?
addio
> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere,
Ingrid meint, ich sollte das spezifizieren. Also: Ich mache einen Text
auf GitHub in einem Brauser auf, markiere ihn auf dem Schirm und
kopiere/paste ihn anschließend in einen Editor auf meinem Rechner ...
und schwupps werden alle Umlaute zu Doppelzeichen ...
Ähnlich wie bei Dir, dafür bei allen nicht-sieben-bit-ASCII ... warum
das dann bei Dir nur beim ü statt findet ... beats me
Frage: Ist da immer ein *spuck* MS Word dabei, oder geht das auch ganz ohne?
addio
Başar Alabay
Jul 14, 2016, 4:31:35 PM7/14/16
to
Andre Igler schrieb:
> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
> allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
> sich UTF noch immer nicht überall herumgesprochen hat.
>
> So weit ich das durchblickt habe, tritt es vor allem cross-platform auf,
> also Win-Texte resp. ISO-latin1 zu meinen Mac, der spricht UTF8.
>
> So oft, dass es mich zu einer tatsächlichen Fehlersuche angeregt hat,
> trat es noch nicht auf ...
Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
ein immer und fortwährend existierendes Problem und hatte irgendwas mit
der »Komposition« (?) des Zeichens zu tun.
B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
> allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
> sich UTF noch immer nicht überall herumgesprochen hat.
>
> So weit ich das durchblickt habe, tritt es vor allem cross-platform auf,
> also Win-Texte resp. ISO-latin1 zu meinen Mac, der spricht UTF8.
>
> So oft, dass es mich zu einer tatsächlichen Fehlersuche angeregt hat,
> trat es noch nicht auf ...
Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
ein immer und fortwährend existierendes Problem und hatte irgendwas mit
der »Komposition« (?) des Zeichens zu tun.
B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
Başar Alabay
Jul 14, 2016, 4:32:41 PM7/14/16
to
Andre Igler schrieb:
> Ingrid meint, ich sollte das spezifizieren. Also: Ich mache einen Text
> auf GitHub in einem Brauser auf, markiere ihn auf dem Schirm und
> kopiere/paste ihn anschließend in einen Editor auf meinem Rechner ...
> und schwupps werden alle Umlaute zu Doppelzeichen ...
>
> Ähnlich wie bei Dir, dafür bei allen nicht-sieben-bit-ASCII ... warum
> das dann bei Dir nur beim ü statt findet ... beats me
>
> Frage: Ist da immer ein *spuck* MS Word dabei, oder geht das auch ganz ohne?
Das hat nix mit Wört oder so zu tun! :-/ Vielleicht klemmt es da
irgendwo bei Adobe. Oder generell im UTF-8 Verfahren, Zeichen
zusammenzusetzen (aufm Mac).
> Ingrid meint, ich sollte das spezifizieren. Also: Ich mache einen Text
> auf GitHub in einem Brauser auf, markiere ihn auf dem Schirm und
> kopiere/paste ihn anschließend in einen Editor auf meinem Rechner ...
> und schwupps werden alle Umlaute zu Doppelzeichen ...
>
> Ähnlich wie bei Dir, dafür bei allen nicht-sieben-bit-ASCII ... warum
> das dann bei Dir nur beim ü statt findet ... beats me
>
> Frage: Ist da immer ein *spuck* MS Word dabei, oder geht das auch ganz ohne?
irgendwo bei Adobe. Oder generell im UTF-8 Verfahren, Zeichen
zusammenzusetzen (aufm Mac).
HC Ahlmann
Jul 14, 2016, 4:51:20 PM7/14/16
to
Andre Igler <an...@invalid.invalid> wrote:
> Frage: Ist da immer ein *spuck* MS Word dabei, oder geht das auch ganz ohne?
Das geht auch ohne aus dem PDF ins CMS (Pansite). Word ist ausnahmsweise
> Frage: Ist da immer ein *spuck* MS Word dabei, oder geht das auch ganz ohne?
nicht der böse Bube.
Ich habe heute mit dem Produktioner jenes Verlags gesprochen, der die
PDF erzeugen lässt; er war gleichermaßen verdutzt, erheitert und ratlos.
Michael Bäuerle
Jul 15, 2016, 3:50:22 AM7/15/16
to
Andre Igler wrote:
> Am 14.07.16 um 11:34 schrieb HC Ahlmann:
> > [ü wird zu u¨, details snipped]
> >
> > Was ist das?
>
> Codierfehler, grundsätzlich mal.
>
> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
> allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
> sich UTF noch immer nicht überall herumgesprochen hat.
Im Gegenteil, nur mit Unicode passiert das. Der Grund ist, dass Unicode
> Am 14.07.16 um 11:34 schrieb HC Ahlmann:
> > [ü wird zu u¨, details snipped]
> >
> > Was ist das?
>
> Codierfehler, grundsätzlich mal.
>
> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
> allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
> sich UTF noch immer nicht überall herumgesprochen hat.
2 Normalformen kennt: Form C (soweit wie möglich zusammengebaut) und
Form D (komplett zerlegt). Beide sind "offiziell", also erlaubt und
gleichwertig ("cannonically equivalent" in den Worten von Unicode).
Für u-Umlaut folgt daraus, dass es 2 gleichwertige Darstellungsformen
gibt:
NFC: U+00FC (LATIN SMALL LETTER U WITH DIAERESIS)
NFD: U+0075 (LATIN SMALL LETTER U), U+0308 (COMBINING DIAERESIS)
Was sich nicht herumgesprochen hat ist, dass man Unicode Text erst
normalisieren muss, damit er sich einheitlich verhält. Sonst kann
man auch nicht vernünftig darin suchen.
--
Im From habe ich meinen Namen zum Test in Form D codiert.
Andre Igler
Jul 15, 2016, 10:53:19 AM7/15/16
to
Am 15.07.16 um 09:46 schrieb Michael Bäuerle:
> Im Gegenteil, nur mit Unicode passiert das. Der Grund ist, dass
> Unicode 2 Normalformen kennt: Form C (soweit wie möglich
> zusammengebaut) und Form D (komplett zerlegt). Beide sind
> "offiziell", also erlaubt und gleichwertig ("cannonically equivalent"
> in den Worten von Unicode).
Aha. Man lernt nie aus.
> Für u-Umlaut folgt daraus, dass es 2 gleichwertige
> Darstellungsformen gibt:
>
> NFC: U+00FC (LATIN SMALL LETTER U WITH DIAERESIS) NFD: U+0075 (LATIN
> SMALL LETTER U), U+0308 (COMBINING DIAERESIS)
ok
> Was sich nicht herumgesprochen hat ist, dass man Unicode Text erst
> normalisieren muss, damit er sich einheitlich verhält.
Und bitte wie "normalisiert" man einen Unicode-Text?
addio
> Im Gegenteil, nur mit Unicode passiert das. Der Grund ist, dass
> Unicode 2 Normalformen kennt: Form C (soweit wie möglich
> zusammengebaut) und Form D (komplett zerlegt). Beide sind
> "offiziell", also erlaubt und gleichwertig ("cannonically equivalent"
> in den Worten von Unicode).
> Für u-Umlaut folgt daraus, dass es 2 gleichwertige
> Darstellungsformen gibt:
>
> NFC: U+00FC (LATIN SMALL LETTER U WITH DIAERESIS) NFD: U+0075 (LATIN
> SMALL LETTER U), U+0308 (COMBINING DIAERESIS)
> Was sich nicht herumgesprochen hat ist, dass man Unicode Text erst
> normalisieren muss, damit er sich einheitlich verhält.
addio
Başar Alabay
Jul 15, 2016, 11:37:53 AM7/15/16
to
Andre Igler schrieb:
>> Für u-Umlaut folgt daraus, dass es 2 gleichwertige
>> Darstellungsformen gibt:
>>
>> NFC: U+00FC (LATIN SMALL LETTER U WITH DIAERESIS) NFD: U+0075 (LATIN
>> SMALL LETTER U), U+0308 (COMBINING DIAERESIS)
> ok
>
>> Was sich nicht herumgesprochen hat ist, dass man Unicode Text erst
>> normalisieren muss, damit er sich einheitlich verhält.
> Und bitte wie "normalisiert" man einen Unicode-Text?
Psychotherapie.
>> Für u-Umlaut folgt daraus, dass es 2 gleichwertige
>> Darstellungsformen gibt:
>>
>> NFC: U+00FC (LATIN SMALL LETTER U WITH DIAERESIS) NFD: U+0075 (LATIN
>> SMALL LETTER U), U+0308 (COMBINING DIAERESIS)
> ok
>
>> Was sich nicht herumgesprochen hat ist, dass man Unicode Text erst
>> normalisieren muss, damit er sich einheitlich verhält.
> Und bitte wie "normalisiert" man einen Unicode-Text?
Michael Bäuerle
Jul 15, 2016, 11:59:44 AM7/15/16
to
Andre Igler wrote:
> Am 15.07.16 um 09:46 schrieb Michael Bäuerle:
> >
> > [...]
Als Implementierung wird oft das fette ICU [2] verwendet.
Ein Programm würde direkt das C/C++ API verwenden, da ist aber auch
ein Kommandozeilentoll namens "uconv" dabei. Beispiel um den Inhalt
einer Textdatei "daten.txt" nach NFC zu normalisieren:
|
| uconv --from-code utf8 --to-code utf8 -x '::nfc;' --output daten_nfc.txt daten.txt
Apple verwendet bei seinen Betriebssystemen an diversen Stellen NFD,
anders als der Rest der Welt. Deswegen sieht man dort oft Probleme, die
aber prinzipiell jederzeit und überall auftreten können (und das gemäß
Unicode auch ganz offiziell dürfen - es ist eben *nicht* nur eine
gültige Codierung definiert, sondern mehrere).
Beispiel:
Für Unicode-Dateinamen die Umlaute enthalten gibt es mehrere gültige
Codierungen (auch solche die weder NFC noch NFD sind, sind deswegen
trotzdem nicht ungültig). Deswegen kann es in einem Verzeichnis mehrere
Dateien des gleichen Namens geben, wenn niemand sich um die
Normalisierung kümmert.
__________________
[1] <http://www.unicode.org/reports/tr15/>
[2] <http://site.icu-project.org/>
> Am 15.07.16 um 09:46 schrieb Michael Bäuerle:
> >
> > [...]
> > Was sich nicht herumgesprochen hat ist, dass man Unicode Text erst
> > normalisieren muss, damit er sich einheitlich verhält.
>
> Und bitte wie "normalisiert" man einen Unicode-Text?
Funktionsweise siehe Unicode Annex #15 [1].
> > normalisieren muss, damit er sich einheitlich verhält.
>
> Und bitte wie "normalisiert" man einen Unicode-Text?
Als Implementierung wird oft das fette ICU [2] verwendet.
Ein Programm würde direkt das C/C++ API verwenden, da ist aber auch
ein Kommandozeilentoll namens "uconv" dabei. Beispiel um den Inhalt
einer Textdatei "daten.txt" nach NFC zu normalisieren:
|
| uconv --from-code utf8 --to-code utf8 -x '::nfc;' --output daten_nfc.txt daten.txt
Apple verwendet bei seinen Betriebssystemen an diversen Stellen NFD,
anders als der Rest der Welt. Deswegen sieht man dort oft Probleme, die
aber prinzipiell jederzeit und überall auftreten können (und das gemäß
Unicode auch ganz offiziell dürfen - es ist eben *nicht* nur eine
gültige Codierung definiert, sondern mehrere).
Beispiel:
Für Unicode-Dateinamen die Umlaute enthalten gibt es mehrere gültige
Codierungen (auch solche die weder NFC noch NFD sind, sind deswegen
trotzdem nicht ungültig). Deswegen kann es in einem Verzeichnis mehrere
Dateien des gleichen Namens geben, wenn niemand sich um die
Normalisierung kümmert.
__________________
[1] <http://www.unicode.org/reports/tr15/>
[2] <http://site.icu-project.org/>
Andre Igler
Jul 15, 2016, 12:21:10 PM7/15/16
to
Am 15.07.16 um 17:58 schrieb Michael Bäuerle:
> | uconv --from-code utf8 --to-code utf8 -x '::nfc;' --output daten_nfc.txt daten.txt
*schluchz* Und wieder was, was ich nicht wissen wollte ...
Und danke für die links, muss ich mal in Ruhe durchlesen.
> | uconv --from-code utf8 --to-code utf8 -x '::nfc;' --output daten_nfc.txt daten.txt
Und danke für die links, muss ich mal in Ruhe durchlesen.
Michael Bäuerle
Jul 15, 2016, 1:22:45 PM7/15/16
to
Andre Igler wrote:
> Am 15.07.16 um 17:58 schrieb Michael Bäuerle:
> >
> > | uconv --from-code utf8 --to-code utf8 -x '::nfc;' --output daten_nfc.txt daten.txt
> *schluchz* Und wieder was, was ich nicht wissen wollte ...
>
> Und danke für die links, muss ich mal in Ruhe durchlesen.
Apple Dateisysteme wie HFS+ verwenden Unicode-Dateinamen und Apple
> Am 15.07.16 um 17:58 schrieb Michael Bäuerle:
> >
> > | uconv --from-code utf8 --to-code utf8 -x '::nfc;' --output daten_nfc.txt daten.txt
> *schluchz* Und wieder was, was ich nicht wissen wollte ...
>
> Und danke für die links, muss ich mal in Ruhe durchlesen.
Betriebssysteme erzwingen wohl auch die korrekte Normalisierung (das
Szenario unten kann man da deswegen nicht so leicht erzeugen).
Auf Dateisystemen die von fremden Maschinen beschrieben wurden (mit
falscher Codierung oder falscher Normalisierung) kann dann aber z.B.
die Situation auftauchen "Datei ist vorhanden, man kann sie aber weder
öffnen noch löschen" ... nicht immer das, was man haben möchte.
Beispiel von einer GNU/Linux Maschine (Dateinamen werden dort vom OS
"as is" durchgereicht, für die Normalisierung sind die Programme bzw.
der User verantwortlich):
|
| $ ls -li
| total 0
| 2138121 -rwx------ 1 baeuerle users 0 Jul 15 19:03 äbä
| 2138120 -rwx------ 1 baeuerle users 0 Jul 15 19:03 äbä
| 2138119 -rwx------ 1 baeuerle users 0 Jul 15 19:03 äbä
| 2138118 -rwx------ 1 baeuerle users 0 Jul 15 19:03 äbä
Die 4 Namen haben (auf Byte-Ebene) verschiedene Codierungen, sind aber
gemäß Unicode alle gültig und sogar "canonically equivalent". Man sieht,
dass es 4 verschiedene Inodes sind, also nicht nur 4 Hardlinks auf die
gleiche Datei. Diese 4 Dateien können also ganz regulär verschiedenen
Inhalt haben. Viele Leute sind sich dessen nicht bewusst, wenn sie
Unicode für Bezeichner (nicht nur Dateinamen) verwenden.
Andre Igler
Jul 16, 2016, 12:08:47 PM7/16/16
to
Am 15.07.16 um 19:22 schrieb Michael Bäuerle:
diesem verblüffenden Szenario stehen, hab' ich eine Lösungsmöglichkeit
Mein größeres Problem ist in Texten.
Reale Problemstellung: $Kumpel & ich arbeiten an Übersetzung, teilen uns
Texte über einen Website. $Kumpel hat ein Linux am Laufen, ich mein
Yosemite. $Kumpel stellt Text auf website, ich kopiere von meinem Schirm
in ein Wordfile, frimmle ein wenig am Text, schicke zurück via Mail,
$Kumpel öffent file -> u¨
Wie verhindere ich das?
> Apple
> Betriebssysteme erzwingen wohl auch die korrekte Normalisierung
Das ordne ich eher unter "gut zu wissen" ein bzw. sollte ich mal vor
> Betriebssysteme erzwingen wohl auch die korrekte Normalisierung
diesem verblüffenden Szenario stehen, hab' ich eine Lösungsmöglichkeit
Mein größeres Problem ist in Texten.
Reale Problemstellung: $Kumpel & ich arbeiten an Übersetzung, teilen uns
Texte über einen Website. $Kumpel hat ein Linux am Laufen, ich mein
Yosemite. $Kumpel stellt Text auf website, ich kopiere von meinem Schirm
in ein Wordfile, frimmle ein wenig am Text, schicke zurück via Mail,
$Kumpel öffent file -> u¨
Wie verhindere ich das?
Peter J. Holzer
Jul 16, 2016, 2:05:26 PM7/16/16
to
On 2016-07-14 20:31, Başar Alabay <ala...@gmx.net> wrote:
> Andre Igler schrieb:
>> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
>> allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
>> sich UTF noch immer nicht überall herumgesprochen hat.
>>
>> So weit ich das durchblickt habe, tritt es vor allem cross-platform auf,
>> also Win-Texte resp. ISO-latin1 zu meinen Mac, der spricht UTF8.
>>
>> So oft, dass es mich zu einer tatsächlichen Fehlersuche angeregt hat,
>> trat es noch nicht auf ...
>
> Nee, nee, das ü in PDF ist schon ein Problem,
Hat nicht wirklich was mit PDF zu tun.
> Andre Igler schrieb:
>> Hier™ bekomme ich das manchmal, wenn ich Texte direkt kopiere¹,
>> allerdings zerfallen dann alle Umlaute. Liegt möglicherweise daran, dass
>> sich UTF noch immer nicht überall herumgesprochen hat.
>>
>> So weit ich das durchblickt habe, tritt es vor allem cross-platform auf,
>> also Win-Texte resp. ISO-latin1 zu meinen Mac, der spricht UTF8.
>>
>> So oft, dass es mich zu einer tatsächlichen Fehlersuche angeregt hat,
>> trat es noch nicht auf ...
>
> Nee, nee, das ü in PDF ist schon ein Problem,
> und zwar kein Windoofs-Ding. Wenn ich tex-Quellen setze und daraus
> dann die üs kopiere, habe ich auch entweder doppelte Zeichen oder nur
> ein u. Das ist ein immer und fortwährend existierendes Problem und
> hatte irgendwas mit der »Komposition« (?) des Zeichens zu tun.
7-Bit (aber nicht US-ASCII, nur so ähnlich) und wurde erst später auf 8 Bit
erweitert. Da die Anzahl der verschiedenen Zeichen in einem Font somit
recht begrenzt war, aber TeX Zeichen beliebig positionieren konnte, lag
es nahe, Zeichen mit Akzenten aus einem Basiszeichen und dem Akzent
zusammenzusetzen: So braucht man nur n+m Zeichen statt n*m.
Soweit ich weiß, macht das (La)TeX bis heute.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Peter J. Holzer
Jul 16, 2016, 2:15:43 PM7/16/16
to
On 2016-07-16 16:08, Andre Igler <an...@invalid.invalid> wrote:
> Reale Problemstellung: $Kumpel & ich arbeiten an Übersetzung, teilen uns
> Texte über einen Website. $Kumpel hat ein Linux am Laufen, ich mein
> Yosemite. $Kumpel stellt Text auf website, ich kopiere von meinem Schirm
> in ein Wordfile, frimmle ein wenig am Text, schicke zurück via Mail,
> $Kumpel öffent file -> u¨
>
> Wie verhindere ich das?
Keine Word-Files verwenden? Bug in Libreoffice (ich nehme mal an,
> Reale Problemstellung: $Kumpel & ich arbeiten an Übersetzung, teilen uns
> Texte über einen Website. $Kumpel hat ein Linux am Laufen, ich mein
> Yosemite. $Kumpel stellt Text auf website, ich kopiere von meinem Schirm
> in ein Wordfile, frimmle ein wenig am Text, schicke zurück via Mail,
> $Kumpel öffent file -> u¨
>
> Wie verhindere ich das?
$Kumpel verwendet Libreoffice, um Deine Word-Files zu lesen) melden und
auf Behebung hoffen? Wenn es schon Word sein muss, das gleiche File
editieren und nicht seltsam herumkopieren?
Andre Igler
Jul 16, 2016, 3:45:58 PM7/16/16
to
Am 16.07.16 um 20:15 schrieb Peter J. Holzer:
Aber klar: brain 2.0 geht immer.
Im Detail: Ich arbeite jetzt in Word seit der Version – äh? 2.0? – oder
so ähnlich. Ich werd' mich auf meine alten Tage ... und die
Wörterbücher, die gesammelten ... außerdem basiert unser workflow auf
Funktionen, die's wo anders, was weiß ich. Aber man kann aus word in
einen reinen .txt file mit mac roman exportieren, das scheint zu
funktionieren.
Ich hoffte, es gäbe etwas Eleganteres. So wie in, da könne man was an
$Einstellung drehen.
Dennoch: Thanx for the info, wieder was gelernt
> On 2016-07-16 16:08, Andre Igler <an...@invalid.invalid> wrote:
>> Reale Problemstellung: $Kumpel & ich arbeiten an Übersetzung, teilen uns
>> Texte über einen Website. $Kumpel hat ein Linux am Laufen, ich mein
>> Yosemite. $Kumpel stellt Text auf website, ich kopiere von meinem Schirm
>> in ein Wordfile, frimmle ein wenig am Text, schicke zurück via Mail,
>> $Kumpel öffent file -> u¨
>>
>> Wie verhindere ich das?
>
> Keine Word-Files verwenden? Bug in Libreoffice (ich nehme mal an,
> $Kumpel verwendet Libreoffice, um Deine Word-Files zu lesen) melden und
> auf Behebung hoffen? Wenn es schon Word sein muss, das gleiche File
> editieren und nicht seltsam herumkopieren?
Jo. Eh. Oder auf Hochdeutsch: Danke, das war mir dann schon klar.
>> Reale Problemstellung: $Kumpel & ich arbeiten an Übersetzung, teilen uns
>> Texte über einen Website. $Kumpel hat ein Linux am Laufen, ich mein
>> Yosemite. $Kumpel stellt Text auf website, ich kopiere von meinem Schirm
>> in ein Wordfile, frimmle ein wenig am Text, schicke zurück via Mail,
>> $Kumpel öffent file -> u¨
>>
>> Wie verhindere ich das?
>
> Keine Word-Files verwenden? Bug in Libreoffice (ich nehme mal an,
> $Kumpel verwendet Libreoffice, um Deine Word-Files zu lesen) melden und
> auf Behebung hoffen? Wenn es schon Word sein muss, das gleiche File
> editieren und nicht seltsam herumkopieren?
Aber klar: brain 2.0 geht immer.
Im Detail: Ich arbeite jetzt in Word seit der Version – äh? 2.0? – oder
so ähnlich. Ich werd' mich auf meine alten Tage ... und die
Wörterbücher, die gesammelten ... außerdem basiert unser workflow auf
Funktionen, die's wo anders, was weiß ich. Aber man kann aus word in
einen reinen .txt file mit mac roman exportieren, das scheint zu
funktionieren.
Ich hoffte, es gäbe etwas Eleganteres. So wie in, da könne man was an
$Einstellung drehen.
Dennoch: Thanx for the info, wieder was gelernt
Michael Bäuerle
Jul 17, 2016, 5:47:39 AM7/17/16
to
Andre Igler wrote:
>
> [...]
deutige Codierung ist (es nur *eine* Codierung für die Umlaute gibt).
Exportiere doch mal Unicode-Daten in das Textfile und schaue dir die
Normalisierung der Umlaute an.
>
> [...]
> Im Detail: Ich arbeite jetzt in Word seit der Version – äh? 2.0? – oder
> so ähnlich. Ich werd' mich auf meine alten Tage ... und die
> Wörterbücher, die gesammelten ... außerdem basiert unser workflow auf
> Funktionen, die's wo anders, was weiß ich. Aber man kann aus word in
> einen reinen .txt file mit mac roman exportieren, das scheint zu
> funktionieren.
Das funktioniert vermutlich genau deswegen, weil Mac Roman eine ein-
> so ähnlich. Ich werd' mich auf meine alten Tage ... und die
> Wörterbücher, die gesammelten ... außerdem basiert unser workflow auf
> Funktionen, die's wo anders, was weiß ich. Aber man kann aus word in
> einen reinen .txt file mit mac roman exportieren, das scheint zu
> funktionieren.
deutige Codierung ist (es nur *eine* Codierung für die Umlaute gibt).
Exportiere doch mal Unicode-Daten in das Textfile und schaue dir die
Normalisierung der Umlaute an.
Andre Igler
Jul 17, 2016, 10:28:28 AM7/17/16
to
Am 17.07.16 um 10:33 schrieb Michael Bäuerle:
> Andre Igler wrote:
>>
>> [...] man kann aus word in einen reinen .txt file mit mac roman
nicht Standard ist. Standard ist Mac Roman, und das erwartet sich mein
Gegenüber. Aber wie schon geposted, auf meinem eigenen Rechner kommt das
nicht vor, und ich verwende auch nicht Latex, das kommt eher beim, äh,
unkonventionellen Textaustausch zwischen Systemen vor. Und manchmal muss
so eine Presseaussendung fix gehen, und dann sitzt einer an einem
Rechner, der nicht ihm gehört, sprich ohne eingerichteten mail client,
und webmail will man nicht wirklich auf fremden Rechnern, ausserdem hab'
ich bislang meinem roundcube das mit dem PGP nicht beibringen können.
Und dann kopiert man halt vom Website runter.
addio.
> Andre Igler wrote:
>>
>> [...] man kann aus word in einen reinen .txt file mit mac roman
>> exportieren, das scheint zu funktionieren.
>
> Das funktioniert vermutlich genau deswegen, weil Mac Roman eine ein-
> deutige Codierung ist (es nur *eine* Codierung für die Umlaute
> gibt).
>
> Exportiere doch mal Unicode-Daten in das Textfile und schaue dir die
> Normalisierung der Umlaute an.
Hamwa schon, hat auch keiner gemeckert. Will ich aber nicht, weil es
>
> Das funktioniert vermutlich genau deswegen, weil Mac Roman eine ein-
> deutige Codierung ist (es nur *eine* Codierung für die Umlaute
> gibt).
>
> Exportiere doch mal Unicode-Daten in das Textfile und schaue dir die
> Normalisierung der Umlaute an.
nicht Standard ist. Standard ist Mac Roman, und das erwartet sich mein
Gegenüber. Aber wie schon geposted, auf meinem eigenen Rechner kommt das
nicht vor, und ich verwende auch nicht Latex, das kommt eher beim, äh,
unkonventionellen Textaustausch zwischen Systemen vor. Und manchmal muss
so eine Presseaussendung fix gehen, und dann sitzt einer an einem
Rechner, der nicht ihm gehört, sprich ohne eingerichteten mail client,
und webmail will man nicht wirklich auf fremden Rechnern, ausserdem hab'
ich bislang meinem roundcube das mit dem PGP nicht beibringen können.
Und dann kopiert man halt vom Website runter.
addio.
Başar Alabay
Jul 24, 2016, 4:28:29 AM7/24/16
to
Dennis Preiser schrieb:
> Başar Alabay <ala...@gmx.net> wrote:
>> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
>> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
>> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
>> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
>> der »Komposition« (?) des Zeichens zu tun.
>
> Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
>
> <http://d--p.de/tmp/2016-07-22.pdf>
Ja. Bei beiden Buchstaben.
> Başar Alabay <ala...@gmx.net> wrote:
>> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
>> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
>> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
>> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
>> der »Komposition« (?) des Zeichens zu tun.
>
>
> <http://d--p.de/tmp/2016-07-22.pdf>
Ja. Bei beiden Buchstaben.
HC Ahlmann
Jul 24, 2016, 4:50:52 AM7/24/16
to
Ba?ar Alabay <ala...@gmx.net> wrote:
> Dennis Preiser schrieb:
> Dennis Preiser schrieb:
>
> > Ba?ar Alabay <ala...@gmx.net> wrote:
> >> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
> >> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
> >> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
> >> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
> >> der »Komposition« (?) des Zeichens zu tun.
> >
> > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
> >
> > <http://d--p.de/tmp/2016-07-22.pdf>
>
> Ja. Bei beiden Buchstaben.
Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
> > Ba?ar Alabay <ala...@gmx.net> wrote:
> >> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
> >> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
> >> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
> >> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
> >> der »Komposition« (?) des Zeichens zu tun.
> >
> > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
> >
> > <http://d--p.de/tmp/2016-07-22.pdf>
>
> Ja. Bei beiden Buchstaben.
MartinC
Jul 24, 2016, 8:04:33 AM7/24/16
to
Am 24.07.16 um 10:24 schrieb Dennis Preiser:
Hier (kopieren aus dem PDF, einsetzen in Textwrangler):
Bei Kopieren in Vorschau sind beide ü kaputt.
Bei Kopieren in Acrobat X Pro ist das erste kleine ü kaputt, aber das
zweite große Ü in Ordnung (das war mir auch noch nicht passiert).
Ich habe das Problem seit geraumer Zeit, daß Dateinamen aus dem Finder
mit Umlauten in Textwrangler als rotes "?" kommen, während es beim
Kopieren zwischen anderen Programmen (z.B. TextEdit, Word, etc.)
funktioniert. Das tieferliegende Problem ist dabei sticky, wenn ich also
einen Dateinamen in TextEdit einfüge und wieder kopiere, und/oder dann
in Word einfüge und wieder kopiere, landet es wieder als "?" in
TextWrangler.
Folglich ist das eine low-level Kodierung, die einige Programme können
(und bewahren) und andere nicht.
Hier (kopieren aus dem PDF, einsetzen in Textwrangler):
Bei Kopieren in Vorschau sind beide ü kaputt.
Bei Kopieren in Acrobat X Pro ist das erste kleine ü kaputt, aber das
zweite große Ü in Ordnung (das war mir auch noch nicht passiert).
Ich habe das Problem seit geraumer Zeit, daß Dateinamen aus dem Finder
mit Umlauten in Textwrangler als rotes "?" kommen, während es beim
Kopieren zwischen anderen Programmen (z.B. TextEdit, Word, etc.)
funktioniert. Das tieferliegende Problem ist dabei sticky, wenn ich also
einen Dateinamen in TextEdit einfüge und wieder kopiere, und/oder dann
in Word einfüge und wieder kopiere, landet es wieder als "?" in
TextWrangler.
Folglich ist das eine low-level Kodierung, die einige Programme können
(und bewahren) und andere nicht.
Steffen Bendix
Jul 24, 2016, 8:29:48 AM7/24/16
to
Bei mir geht's auch per Vorschau, Safari und Evernote.
Steffen
Steffen
Başar Alabay
Jul 24, 2016, 12:04:15 PM7/24/16
to
HC Ahlmann schrieb:
>> > Ba?ar Alabay <ala...@gmx.net> wrote:
>> >> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
>> >> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
>> >> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
>> >> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
>> >> der »Komposition« (?) des Zeichens zu tun.
>> >
>> > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
>> >
>> > <http://d--p.de/tmp/2016-07-22.pdf>
>>
>> Ja. Bei beiden Buchstaben.
>
> Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
Moment, ich habe was anderes ausprobiert! Nämlich, ob diese beiden ü in
einem TeX-Quelltext nach dem Setzen auch als ü abgebildet werden.
Und das tun sie nicht, es werden … u. »Einfach so« rauskopiert sieht das
aus wie ü. Es ist dann aber keines ;-)
>> > Ba?ar Alabay <ala...@gmx.net> wrote:
>> >> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
>> >> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
>> >> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
>> >> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
>> >> der »Komposition« (?) des Zeichens zu tun.
>> >
>> > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
>> >
>> > <http://d--p.de/tmp/2016-07-22.pdf>
>>
>> Ja. Bei beiden Buchstaben.
>
> Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
einem TeX-Quelltext nach dem Setzen auch als ü abgebildet werden.
Und das tun sie nicht, es werden … u. »Einfach so« rauskopiert sieht das
aus wie ü. Es ist dann aber keines ;-)
Başar Alabay
Jul 24, 2016, 12:07:30 PM7/24/16
to
> Problem auch mit Apples Vorschau auf?
Ja. Ja.
Wie gesagt … es geht um TeX. Wenn ich das in ein txt-Dokument einfüge,
sieht es aus wie ein ü. Aber wenn das ein TeX-Quelltext ist, ist im
gesetzten Ergebnis kein ü mehr, sondern ein u.
Başar Alabay
Jul 24, 2016, 12:09:41 PM7/24/16
to
MartinC schrieb:
> Am 24.07.16 um 10:24 schrieb Dennis Preiser:
>
>> Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
>>
>> <http://d--p.de/tmp/2016-07-22.pdf>
>
> Hier (kopieren aus dem PDF, einsetzen in Textwrangler):
>
> Bei Kopieren in Vorschau sind beide ü kaputt.
Hier beide ü (theoretisch) ganz.
> Bei Kopieren in Acrobat X Pro ist das erste kleine ü kaputt, aber das
> zweite große Ü in Ordnung (das war mir auch noch nicht passiert).
Auch beide (thepretisch) ganz.
… in TextWrangler.
In TeX-Shop auch noch ein ü. Im gesetzten Text-PDF dann keines mehr.
Die anderen Probleme habe ich nicht.
> Am 24.07.16 um 10:24 schrieb Dennis Preiser:
>
>> Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
>>
>> <http://d--p.de/tmp/2016-07-22.pdf>
>
> Hier (kopieren aus dem PDF, einsetzen in Textwrangler):
>
> Bei Kopieren in Vorschau sind beide ü kaputt.
> Bei Kopieren in Acrobat X Pro ist das erste kleine ü kaputt, aber das
> zweite große Ü in Ordnung (das war mir auch noch nicht passiert).
… in TextWrangler.
In TeX-Shop auch noch ein ü. Im gesetzten Text-PDF dann keines mehr.
Die anderen Probleme habe ich nicht.
Juergen P. Meier
Jul 25, 2016, 1:35:19 AM7/25/16
to
HC Ahlmann <hc.ah...@gmx.de>:
ISO-8859-1[5] identisch ist).
Dennis' PDF-Software muss schon sehr kaputt sein, um daraus jeweils
zwei Zeichen zu erbrechen, auch wenn das Dokument keinem PDF-Standard
genuegt.
> Ba?ar Alabay <ala...@gmx.net> wrote:
>
>> Dennis Preiser schrieb:
>>
>> > Ba?ar Alabay <ala...@gmx.net> wrote:
>> >> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
>> >> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
>> >> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
>> >> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
>> >> der »Komposition« (?) des Zeichens zu tun.
>> >
>> > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
>> >
>> > <http://d--p.de/tmp/2016-07-22.pdf>
>>
>> Ja. Bei beiden Buchstaben.
>
> Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
Und zwar üÜ nach ISO-Kodierung (genauer: UTF-8 single-byte code der mit
>
>> Dennis Preiser schrieb:
>>
>> > Ba?ar Alabay <ala...@gmx.net> wrote:
>> >> Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
>> >> Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
>> >> kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
>> >> ein immer und fortwährend existierendes Problem und hatte irgendwas mit
>> >> der »Komposition« (?) des Zeichens zu tun.
>> >
>> > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
>> >
>> > <http://d--p.de/tmp/2016-07-22.pdf>
>>
>> Ja. Bei beiden Buchstaben.
>
> Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
ISO-8859-1[5] identisch ist).
Dennis' PDF-Software muss schon sehr kaputt sein, um daraus jeweils
zwei Zeichen zu erbrechen, auch wenn das Dokument keinem PDF-Standard
genuegt.
MartinC
Jul 25, 2016, 3:47:21 AM7/25/16
to
Am 24.07.16 um 18:09 schrieb Başar Alabay:
> Auch beide (thepretisch) ganz.
>
> … in TextWrangler.
Danke für die Info - wobei es mich nicht überrascht, denn wenn das
überall auftreten würde, wäre es TextWrangler schon um die Ohren
geflogen (hab die kontaktiert und sie können es nicht nachvollziehen).
Das Problem ist irgendwann aufgetaucht und besteht seitdem. Ich vermute
mal irgendeine sehr obskure Prefs-Einstellung, die ich aber nicht finde...
Falls sich jemand mit sowas auskennt: das üÜ aus dem PDF in TextWrangler
eingesetzt führt zu einem roten ? für das erste ü (damit werden Gremlins
signalisiert) und einem korrekt dargestellten zweiten Ü dahinter.
Es spielt keine Rolle, welches Encoding für das offene Fenster gewählt
ist. Sichere ich den Text (als UTF-8) ergibt sich in Hex folgender
Inhalt: 75 CC 88 55
Sämtliche anderen Programme (selbst das Terminal) stellen das üÜ korrekt
dar, und Copy/Paste erhält den Zustand (samt Problem) in beliebiger Kette.
Erst wenn ich in einem anderen Programm selbst üÜ eintippe und kopiere
kommt es in TextWrangler sauber an. Und als Urheber dieses Phänomens
kannte ich (vor diesem PDF jetzt) nur Dateinamen im Finder.
> Auch beide (thepretisch) ganz.
>
> … in TextWrangler.
überall auftreten würde, wäre es TextWrangler schon um die Ohren
geflogen (hab die kontaktiert und sie können es nicht nachvollziehen).
Das Problem ist irgendwann aufgetaucht und besteht seitdem. Ich vermute
mal irgendeine sehr obskure Prefs-Einstellung, die ich aber nicht finde...
Falls sich jemand mit sowas auskennt: das üÜ aus dem PDF in TextWrangler
eingesetzt führt zu einem roten ? für das erste ü (damit werden Gremlins
signalisiert) und einem korrekt dargestellten zweiten Ü dahinter.
Es spielt keine Rolle, welches Encoding für das offene Fenster gewählt
ist. Sichere ich den Text (als UTF-8) ergibt sich in Hex folgender
Inhalt: 75 CC 88 55
Sämtliche anderen Programme (selbst das Terminal) stellen das üÜ korrekt
dar, und Copy/Paste erhält den Zustand (samt Problem) in beliebiger Kette.
Erst wenn ich in einem anderen Programm selbst üÜ eintippe und kopiere
kommt es in TextWrangler sauber an. Und als Urheber dieses Phänomens
kannte ich (vor diesem PDF jetzt) nur Dateinamen im Finder.
Michael Bäuerle
Jul 25, 2016, 4:39:41 AM7/25/16
to
Başar Alabay wrote:
> HC Ahlmann schrieb:
> >
> > [...]
nicht Bug).
> HC Ahlmann schrieb:
> >
> > [...]
> > Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
>
> Moment, ich habe was anderes ausprobiert! Nämlich, ob diese beiden ü in
> einem TeX-Quelltext nach dem Setzen auch als ü abgebildet werden.
> Und das tun sie nicht, es werden … u. »Einfach so« rauskopiert sieht das
> aus wie ü. Es ist dann aber keines ;-)
Ich möchte wetten, dass es gemäß Unicode eben doch eines ist (Feature,
>
> Moment, ich habe was anderes ausprobiert! Nämlich, ob diese beiden ü in
> einem TeX-Quelltext nach dem Setzen auch als ü abgebildet werden.
> Und das tun sie nicht, es werden … u. »Einfach so« rauskopiert sieht das
> aus wie ü. Es ist dann aber keines ;-)
nicht Bug).
Michael Bäuerle
Jul 25, 2016, 4:55:20 AM7/25/16
to
MartinC wrote:
> Am 24.07.16 um 18:09 schrieb Başar Alabay:
> >
> > Auch beide (thepretisch) ganz.
> >
> > … in TextWrangler.
>
> Danke für die Info - wobei es mich nicht überrascht, denn wenn das
> überall auftreten würde, wäre es TextWrangler schon um die Ohren
> geflogen (hab die kontaktiert und sie können es nicht nachvollziehen).
>
> Das Problem ist irgendwann aufgetaucht und besteht seitdem. Ich vermute
> mal irgendeine sehr obskure Prefs-Einstellung, die ich aber nicht
> finde...
>
> Falls sich jemand mit sowas auskennt: das üÜ aus dem PDF in
> TextWrangler eingesetzt führt zu einem roten ? für das erste ü (damit
> werden Gremlins signalisiert) und einem korrekt dargestellten zweiten Ü
> dahinter.
>
> Es spielt keine Rolle, welches Encoding für das offene Fenster gewählt
> ist. Sichere ich den Text (als UTF-8) ergibt sich in Hex folgender
> Inhalt: 75 CC 88 55
UTF-8 Unicode codepoint
> Am 24.07.16 um 18:09 schrieb Başar Alabay:
> >
> > Auch beide (thepretisch) ganz.
> >
> > … in TextWrangler.
>
> Danke für die Info - wobei es mich nicht überrascht, denn wenn das
> überall auftreten würde, wäre es TextWrangler schon um die Ohren
> geflogen (hab die kontaktiert und sie können es nicht nachvollziehen).
>
> Das Problem ist irgendwann aufgetaucht und besteht seitdem. Ich vermute
> mal irgendeine sehr obskure Prefs-Einstellung, die ich aber nicht
> finde...
>
> Falls sich jemand mit sowas auskennt: das üÜ aus dem PDF in
> TextWrangler eingesetzt führt zu einem roten ? für das erste ü (damit
> werden Gremlins signalisiert) und einem korrekt dargestellten zweiten Ü
> dahinter.
>
> Es spielt keine Rolle, welches Encoding für das offene Fenster gewählt
> ist. Sichere ich den Text (als UTF-8) ergibt sich in Hex folgender
> Inhalt: 75 CC 88 55
-----------------------------------------
75 U+0075 (LATIN SMALL LETTER U)
CC 88 U+0308 (COMBINING DIAERESIS)
55 U+0055 (LATIN CAPITAL LETTER U)
Das ergäbe "üU" (das große U dürfte so kein Umlaut sein, wenn da nicht
nochmal U+0308 , also CC 88 folgt).
Das kleine 'ü' ist so gemäß Unicode und UTF-8 aber völlig korrekt
codiert (Normal Form D).
> Sämtliche anderen Programme (selbst das Terminal) stellen das üÜ
> korrekt dar, und Copy/Paste erhält den Zustand (samt Problem) in
> beliebiger Kette.
>
> Erst wenn ich in einem anderen Programm selbst üÜ eintippe und kopiere
> kommt es in TextWrangler sauber an. Und als Urheber dieses Phänomens
> kannte ich (vor diesem PDF jetzt) nur Dateinamen im Finder.
HC Ahlmann
Jul 25, 2016, 6:24:32 AM7/25/16
to
MartinC <nor...@nospam.invalid> wrote:
> Falls sich jemand mit sowas auskennt: das üÜ aus dem PDF in TextWrangler
> eingesetzt führt zu einem roten ? für das erste ü (damit werden Gremlins
> signalisiert) und einem korrekt dargestellten zweiten Ü dahinter.
PDF-Anzeige in Firefox 47.0 oder Adobe Reader per C&P nach Textwrangler
> Falls sich jemand mit sowas auskennt: das üÜ aus dem PDF in TextWrangler
> eingesetzt führt zu einem roten ? für das erste ü (damit werden Gremlins
> signalisiert) und einem korrekt dargestellten zweiten Ü dahinter.
ergibt bei mir ü Ü ohne Gremlins. Auch aus der Vorschau kommen per C&P
zwei ü nach Textwrangler, aber ohne Leerzeichen dazwischen: üÜ
Aber bei C&P vom Adobe Reader nach Word zerfällt das kleine ü in u und
Diaresis, bei Vorschau nach Word nicht. Bei einem anderen PDF zeigte
sich, dass dafür alle Leerzeichen in jener Zeile fehlen, die das ü
enthielt, in den übrigen Zeilen Leerzeichen übertragen werden.
Michael Bäuerle
Jul 25, 2016, 6:31:22 AM7/25/16
to
Juergen P. Meier wrote:
> HC Ahlmann <hc.ah...@gmx.de>:
> ISO-8859-1[5] identisch ist).
Dual-byte in UTF-8 (C3 BC bzw. C3 9C), aber gleiche Codepoints (dar-
stellbar mit 8 Bit) in Unicode und ISO 8859-1.
> HC Ahlmann <hc.ah...@gmx.de>:
> > > > Başar Alabay <ala...@gmx.net> wrote:
> > > > >
> > > > > Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
> > > > > Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
> > > > > kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
> > > > > ein immer und fortwährend existierendes Problem und hatte irgendwas mit
> > > > > der »Komposition« (?) des Zeichens zu tun.
> > > >
> > > > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
> > > >
> > > > <http://d--p.de/tmp/2016-07-22.pdf>
> > >
> > > Ja. Bei beiden Buchstaben.
> >
> > Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
>
> Und zwar üÜ nach ISO-Kodierung (genauer: UTF-8 single-byte code der mit
^^^^^^^^^^^
> > > > >
> > > > > Nee, nee, das ü in PDF ist schon ein Problem, und zwar kein
> > > > > Windoofs-Ding. Wenn ich tex-Quellen setze und daraus dann die üs
> > > > > kopiere, habe ich auch entweder doppelte Zeichen oder nur ein u. Das ist
> > > > > ein immer und fortwährend existierendes Problem und hatte irgendwas mit
> > > > > der »Komposition« (?) des Zeichens zu tun.
> > > >
> > > > Tritt das bei Dir auch mit den 'ü's aus diesem pdf auf:
> > > >
> > > > <http://d--p.de/tmp/2016-07-22.pdf>
> > >
> > > Ja. Bei beiden Buchstaben.
> >
> > Das ist lustig, ich bekomme aus Denis' PDF zwei ü per c&p.
>
> Und zwar üÜ nach ISO-Kodierung (genauer: UTF-8 single-byte code der mit
> ISO-8859-1[5] identisch ist).
Dual-byte in UTF-8 (C3 BC bzw. C3 9C), aber gleiche Codepoints (dar-
stellbar mit 8 Bit) in Unicode und ISO 8859-1.
Juergen P. Meier
Jul 25, 2016, 7:15:46 AM7/25/16
to
Michael Bäuerle <michael....@stz-e.de>:
"copy" in die Zeischenablage.
>> Und zwar üÜ nach ISO-Kodierung (genauer: UTF-8 single-byte code der mit
> ^^^^^^^^^^^
>> ISO-8859-1[5] identisch ist).
>
> Dual-byte in UTF-8 (C3 BC bzw. C3 9C), aber gleiche Codepoints (dar-
> stellbar mit 8 Bit) in Unicode und ISO 8859-1.
Hmpf, dann konvertiert das schon mein PDF-Viewer spaetestens vor dem
> ^^^^^^^^^^^
>> ISO-8859-1[5] identisch ist).
>
> Dual-byte in UTF-8 (C3 BC bzw. C3 9C), aber gleiche Codepoints (dar-
> stellbar mit 8 Bit) in Unicode und ISO 8859-1.
"copy" in die Zeischenablage.
Michael Bäuerle
Jul 25, 2016, 7:47:00 AM7/25/16
to
Juergen P. Meier wrote:
> Michael Bäuerle <michael....@stz-e.de>:
Ich hatte den Text mit pdftotext (gehört laut man page zu xpdf)
extrahiert:
|
| $ pdftotext 2016-07-22.pdf 2016-07-22.txt
Raus kam:
|
| $ od -t x1 2016-07-22.txt
| 0000000 c3 bc c3 9c 0a 0a 31 0a 0a 0c
^^^^^^ ^^^^^^
... Unicode in UTF-8 und NFC, obwohl meine Locale so eingestellt war:
|
| LC_CTYPE="en_US.ISO8859-1"
Ich gehe daher mal davon aus, dass da nichts konvertiert (und auch nicht
normalisiert) wurde, es also im PDF so drin steht.
> Michael Bäuerle <michael....@stz-e.de>:
extrahiert:
|
| $ pdftotext 2016-07-22.pdf 2016-07-22.txt
Raus kam:
|
| $ od -t x1 2016-07-22.txt
| 0000000 c3 bc c3 9c 0a 0a 31 0a 0a 0c
^^^^^^ ^^^^^^
... Unicode in UTF-8 und NFC, obwohl meine Locale so eingestellt war:
|
| LC_CTYPE="en_US.ISO8859-1"
Ich gehe daher mal davon aus, dass da nichts konvertiert (und auch nicht
normalisiert) wurde, es also im PDF so drin steht.
MartinC
Jul 25, 2016, 10:14:50 AM7/25/16
to
Am 25.07.16 um 10:53 schrieb Michael Bäuerle:
> UTF-8 Unicode codepoint
> -----------------------------------------
> 75 U+0075 (LATIN SMALL LETTER U)
> CC 88 U+0308 (COMBINING DIAERESIS)
> 55 U+0055 (LATIN CAPITAL LETTER U)
>
> Das ergäbe "üU" (das große U dürfte so kein Umlaut sein, wenn da nicht
> nochmal U+0308 , also CC 88 folgt).
>
> Das kleine 'ü' ist so gemäß Unicode und UTF-8 aber völlig korrekt
> codiert (Normal Form D).
Stimmt... und es ist sogar noch merkwürdiger.
Wenn ich in Vorschau das üÜ selektiere (bis zum "Zeilenende") dann
kopiert es mir tatsächlich üU, wobei das U in TextWrangler korrekt ist.
Nur wenn ich alles selektiere (also die Seite bis zur Ziffer "1" unten)
bekomme ich in TextWrangler zwei Gremlins.
In Acrobat X Pro genügt es, oben üÜ zu selektieren, um beide Gremlins zu
bekommen. Das heißt nur Vorschau glaubt, die Zeile endet mit einem U und
ignoriert den Zusatz (obwohl es als Ü erscheint und selektiert ist).
Wäre es denkbar, daß die Zeichen zwar korrekt codiert sind, aber aus
irgend einem Grund in der Zwischenablage als etwas anderes landen? Denn
wenn es nur ein Bug in TextWrangler wäre, ist es komisch, daß Vorschau
ebenfalls Probleme hat, das zweite Ü zu kopieren, obwohl es ja korrekt
dargestellt wird. Da läuft irgendwas gegeneinander.
> UTF-8 Unicode codepoint
> -----------------------------------------
> 75 U+0075 (LATIN SMALL LETTER U)
> CC 88 U+0308 (COMBINING DIAERESIS)
> 55 U+0055 (LATIN CAPITAL LETTER U)
>
> Das ergäbe "üU" (das große U dürfte so kein Umlaut sein, wenn da nicht
> nochmal U+0308 , also CC 88 folgt).
>
> Das kleine 'ü' ist so gemäß Unicode und UTF-8 aber völlig korrekt
> codiert (Normal Form D).
Wenn ich in Vorschau das üÜ selektiere (bis zum "Zeilenende") dann
kopiert es mir tatsächlich üU, wobei das U in TextWrangler korrekt ist.
Nur wenn ich alles selektiere (also die Seite bis zur Ziffer "1" unten)
bekomme ich in TextWrangler zwei Gremlins.
In Acrobat X Pro genügt es, oben üÜ zu selektieren, um beide Gremlins zu
bekommen. Das heißt nur Vorschau glaubt, die Zeile endet mit einem U und
ignoriert den Zusatz (obwohl es als Ü erscheint und selektiert ist).
Wäre es denkbar, daß die Zeichen zwar korrekt codiert sind, aber aus
irgend einem Grund in der Zwischenablage als etwas anderes landen? Denn
wenn es nur ein Bug in TextWrangler wäre, ist es komisch, daß Vorschau
ebenfalls Probleme hat, das zweite Ü zu kopieren, obwohl es ja korrekt
dargestellt wird. Da läuft irgendwas gegeneinander.
MartinC
Jul 25, 2016, 11:13:28 AM7/25/16
to
Am 25.07.16 um 10:53 schrieb Michael Bäuerle:
> UTF-8 Unicode codepoint
> -----------------------------------------
> 75 U+0075 (LATIN SMALL LETTER U)
> CC 88 U+0308 (COMBINING DIAERESIS)
> 55 U+0055 (LATIN CAPITAL LETTER U)
>
> Das ergäbe "üU" (das große U dürfte so kein Umlaut sein, wenn da nicht
> nochmal U+0308 , also CC 88 folgt).
Hab den Test nochmal mit allem selektierten Text wiederholt und
> -----------------------------------------
> 75 U+0075 (LATIN SMALL LETTER U)
> CC 88 U+0308 (COMBINING DIAERESIS)
> 55 U+0055 (LATIN CAPITAL LETTER U)
>
> Das ergäbe "üU" (das große U dürfte so kein Umlaut sein, wenn da nicht
> nochmal U+0308 , also CC 88 folgt).
natürlich entsteht dann 75 CC 88 55 CC 88
>uconv --from-code utf8 --to-code utf8 -x '::nfc;' --output daten_nfc.txt
verwenden.
Damit hab ich den naiven Versuch unternommen, das Problem mit
AppleScript zu lösen (welches sich bequem in TextWrangler einbauen ließe):
set temp to the clipboard
set the clipboard to (do shell script "echo \"" & temp & "\" | iconv
-t UTF-8-MAC")
Das funktioniert aber schon mal nicht, denn TextWrangler bleibt bei "Ein
Gremlin ist ein Gremlin ist ein Gremlin" :-/
Also war das entweder wirklich zu naiv gedacht, oder man braucht uconv
(hier aktuell ein 10.6 Rechner, gibt's das irgendwo nachzurüsten?)
Übrigens - ein Versuch mit UTF-16 führt zu einer größeren Strecke
Gremlins. Was auch immer da in der Zwischenanlage ist, wird also von
TextWrangler überhaupt nicht als UTF erkannt.
MartinC
Jul 25, 2016, 11:32:03 AM7/25/16
to
Am 25.07.16 um 17:13 schrieb MartinC:
(Sorry wegen der partiellen Entführung zu TextWrangler, aber ich denke
das Grundproblem hier ist das selbe).
Ich habe im Netz etwas Semi-Sachdienliches gefunden, und zwar der etwas
verpeilte Ratschlag in einem TW-Forum, man solle "show invisibles"
abschalten.
Und in klassischer Hotline-Manier mildert das das Problem tatsächlich
kosmetisch, ohne die Ursache anzugehen - denn ohne "show invisibles"
sehe ich plötzlich üÜ wie es sein soll.
Als Lösung ist das allerdings Kappes, weil es 1) lediglich den einen Bug
durch einen anderen ersetzt (denn dann müßte man statt ?? eigentlich
u?U? sehen) und es 2) vor allem nichts an der kaputten Kodierung öndert,
denn in einem anderen Encoding (wie z.B. MacRoman) läßt sich das
Dokument nicht sichern, weil "unmappable" Zeichen drin sind, die UTF
erfordern (HaHa, lustig).
Ein selbstgestrickter Workaround wäre wohl wirklich irgendetwas, das UTF
in der Zwischenablage dort normalisiert - also z.B. sowas wie das
AppleScript/DoShellScript, nur halt in "funktioniert"... wüßte da jemand
Hilfe? Doch uconv?
(Sorry wegen der partiellen Entführung zu TextWrangler, aber ich denke
das Grundproblem hier ist das selbe).
Ich habe im Netz etwas Semi-Sachdienliches gefunden, und zwar der etwas
verpeilte Ratschlag in einem TW-Forum, man solle "show invisibles"
abschalten.
Und in klassischer Hotline-Manier mildert das das Problem tatsächlich
kosmetisch, ohne die Ursache anzugehen - denn ohne "show invisibles"
sehe ich plötzlich üÜ wie es sein soll.
Als Lösung ist das allerdings Kappes, weil es 1) lediglich den einen Bug
durch einen anderen ersetzt (denn dann müßte man statt ?? eigentlich
u?U? sehen) und es 2) vor allem nichts an der kaputten Kodierung öndert,
denn in einem anderen Encoding (wie z.B. MacRoman) läßt sich das
Dokument nicht sichern, weil "unmappable" Zeichen drin sind, die UTF
erfordern (HaHa, lustig).
Ein selbstgestrickter Workaround wäre wohl wirklich irgendetwas, das UTF
in der Zwischenablage dort normalisiert - also z.B. sowas wie das
AppleScript/DoShellScript, nur halt in "funktioniert"... wüßte da jemand
Hilfe? Doch uconv?
MartinC
Jul 25, 2016, 11:44:34 AM7/25/16
to
Hurray, der da hat geholfen:
http://apple.stackexchange.com/questions/83935/unicode-normalization-for-filenames-and-copied-text-from-pdfs
Warum auch immer... aber entscheidend ist, was hinten rauskommt, und
dieses AppleScript löst mein Problem:
set the clipboard to (do shell script "echo \"" & (the clipboard) & "\"
| iconv -f utf-8-mac -t UTF-8")
@ HC Ahlman : Versuch doch mal, ob das auch bei Dir die Zeichen säubert.
Michael Bäuerle
Jul 25, 2016, 12:08:05 PM7/25/16
to
MartinC wrote:
> Am 25.07.16 um 10:53 schrieb Michael Bäuerle:
> >
> > UTF-8 Unicode codepoint
> > -----------------------------------------
> > 75 U+0075 (LATIN SMALL LETTER U)
> > CC 88 U+0308 (COMBINING DIAERESIS)
> > 55 U+0055 (LATIN CAPITAL LETTER U)
> >
> > Das ergäbe "üU" (das große U dürfte so kein Umlaut sein, wenn da nicht
> > nochmal U+0308 , also CC 88 folgt).
> >
> > Das kleine 'ü' ist so gemäß Unicode und UTF-8 aber völlig korrekt
> > codiert (Normal Form D).
>
> Stimmt... und es ist sogar noch merkwürdiger.
>
> Wenn ich in Vorschau das üÜ selektiere (bis zum "Zeilenende") dann
> kopiert es mir tatsächlich üU, wobei das U in TextWrangler korrekt ist.
>
> Nur wenn ich alles selektiere (also die Seite bis zur Ziffer "1" unten)
> bekomme ich in TextWrangler zwei Gremlins.
>
> In Acrobat X Pro genügt es, oben üÜ zu selektieren, um beide Gremlins
> zu bekommen. Das heißt nur Vorschau glaubt, die Zeile endet mit einem U
> und ignoriert den Zusatz (obwohl es als Ü erscheint und selektiert ist).
Ja, das deutet darauf hin, dass dort die Selektions-Implementierung
> Am 25.07.16 um 10:53 schrieb Michael Bäuerle:
> >
> > UTF-8 Unicode codepoint
> > -----------------------------------------
> > 75 U+0075 (LATIN SMALL LETTER U)
> > CC 88 U+0308 (COMBINING DIAERESIS)
> > 55 U+0055 (LATIN CAPITAL LETTER U)
> >
> > Das ergäbe "üU" (das große U dürfte so kein Umlaut sein, wenn da nicht
> > nochmal U+0308 , also CC 88 folgt).
> >
> > Das kleine 'ü' ist so gemäß Unicode und UTF-8 aber völlig korrekt
> > codiert (Normal Form D).
>
> Stimmt... und es ist sogar noch merkwürdiger.
>
> Wenn ich in Vorschau das üÜ selektiere (bis zum "Zeilenende") dann
> kopiert es mir tatsächlich üU, wobei das U in TextWrangler korrekt ist.
>
> Nur wenn ich alles selektiere (also die Seite bis zur Ziffer "1" unten)
> bekomme ich in TextWrangler zwei Gremlins.
>
> In Acrobat X Pro genügt es, oben üÜ zu selektieren, um beide Gremlins
> zu bekommen. Das heißt nur Vorschau glaubt, die Zeile endet mit einem U
> und ignoriert den Zusatz (obwohl es als Ü erscheint und selektiert ist).
nicht richtig mit Unicode-Daten umgehen kann wenn zerlegte Zeichen
vorkommen (was nicht konform sein kann, denn für vieles in Unicode gibt
es keine komplett zusammengebauten Varianten).
> Wäre es denkbar, daß die Zeichen zwar korrekt codiert sind, aber aus
> irgend einem Grund in der Zwischenablage als etwas anderes landen? Denn
> wenn es nur ein Bug in TextWrangler wäre, ist es komisch, daß Vorschau
> ebenfalls Probleme hat, das zweite Ü zu kopieren, obwohl es ja korrekt
> dargestellt wird. Da läuft irgendwas gegeneinander.
"canonically equivalent" definiert ist, sich gleich verhalten. Also
u.a. gleich angezeigt werden und beim Vergleich von Strings als "gleich"
durchgehen - auch wenn die Codierung verschieden ist.
Vermutlich gibt es auf Apple-Rechnern aber eine Vorschrift für die
Zwischenablage (ähnlich wie für die Dateinamen im HFS+ Dateisystem).
Da kenne ich leider keine Details.
Michael Bäuerle
Jul 25, 2016, 3:18:52 PM7/25/16
to
Dennis Preiser wrote:
> Das Problem scheint hier das verwendete LaTeX zu sein. Mit XeLaTeX
> sollte es, wie hier beschrieben, funktionieren:
>
> <http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8̈-not>
>
> Dennis
>
> PS: Klasse Link, mal sehen ob das gut geht ;-)
> ansonsten: <http://tex.stackexchange.com/questions/94418/>
Hier funktioniert beides. Ich glaube die erste Variante ist aber nicht
legal. RFC3986 [1] definiert da nur US-ASCII wenn ich das richtig sehe.
'ALPHA' ist in RFC2234 [2] definiert als:
|
| ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
Non-ASCII Zeichen scheinen also generell Prozentcodierung zu brauchen.
So müsste es auf jeden Fall legal sein:
<http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8%CC%88-not>
______________________
[1] <https://tools.ietf.org/html/rfc3986#section-2.3>
[2] <https://tools.ietf.org/html/rfc2234#section-6.1>
> sollte es, wie hier beschrieben, funktionieren:
>
> <http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8̈-not>
>
> Dennis
>
> PS: Klasse Link, mal sehen ob das gut geht ;-)
> ansonsten: <http://tex.stackexchange.com/questions/94418/>
Hier funktioniert beides. Ich glaube die erste Variante ist aber nicht
legal. RFC3986 [1] definiert da nur US-ASCII wenn ich das richtig sehe.
'ALPHA' ist in RFC2234 [2] definiert als:
|
| ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
Non-ASCII Zeichen scheinen also generell Prozentcodierung zu brauchen.
So müsste es auf jeden Fall legal sein:
<http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8%CC%88-not>
______________________
[1] <https://tools.ietf.org/html/rfc3986#section-2.3>
[2] <https://tools.ietf.org/html/rfc2234#section-6.1>
Michael Bäuerle
Jul 25, 2016, 3:45:12 PM7/25/16
to
C&P.
Wenn ich die erste Variante durch den URI-Encoder schicke, kommt sie
unverändert raus. Akzeptiert wird sie beim anklicken dann aber nicht:
|
| flnews: EXT: Invalid characters in URI
Das darf man wohl als Bug betrachten ...
[Neues Subject, Xpost und Fup2 in die Testgruppe]
Başar Alabay
Jul 26, 2016, 2:10:40 AM7/26/16
to
Dennis Preiser schrieb:
> PS: Klasse Link, mal sehen ob das gut geht ;-)
> ansonsten: <http://tex.stackexchange.com/questions/94418/>
Obiges ging gut und ließ sich nicht durch »u8̈« stören :-)
> Das Problem scheint hier das verwendete LaTeX zu sein. Mit XeLaTeX
> sollte es, wie hier beschrieben, funktionieren:
>
> <http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8̈-not>
Ich benutze LuaLaTeX :-)
> sollte es, wie hier beschrieben, funktionieren:
>
> <http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8̈-not>
> PS: Klasse Link, mal sehen ob das gut geht ;-)
> ansonsten: <http://tex.stackexchange.com/questions/94418/>
Michael Bäuerle
Jul 26, 2016, 10:19:50 AM7/26/16
to
> Das Problem scheint hier das verwendete LaTeX zu sein. Mit XeLaTeX
> sollte es, wie hier beschrieben, funktionieren:
>
> <http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8̈-not>
>
> Dennis
> sollte es, wie hier beschrieben, funktionieren:
>
> <http://tex.stackexchange.com/questions/94418/os-x-umlauts-in-utf8-nfd-yield-package-inputenc-error-unicode-char-u8̈-not>
>
>
> PS: Klasse Link, mal sehen ob das gut geht ;-)
> ansonsten: <http://tex.stackexchange.com/questions/94418/>
Zum Thema HFS+ Dateinamen noch dieser Link:
> PS: Klasse Link, mal sehen ob das gut geht ;-)
> ansonsten: <http://tex.stackexchange.com/questions/94418/>
<https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties>
Was dort verwendet wird ist weder NFC noch NFD nach aktueller Norm, d.h.
ein Treiber der auf dieses Dateisystem schreiben möchte braucht
spezielle Routinen zur Normalisierung der Dateinamen.
MartinC
Jul 27, 2016, 5:28:09 AM7/27/16
to
Am 26.07.16 um 16:12 schrieb Michael Bäuerle:
> Zum Thema HFS+ Dateinamen noch dieser Link:
> <https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties>
>
> Was dort verwendet wird ist weder NFC noch NFD nach aktueller Norm, d.h.
> ein Treiber der auf dieses Dateisystem schreiben möchte braucht
> spezielle Routinen zur Normalisierung der Dateinamen.
Das dürfte hier nicht die Ursache des Problems sein, da keine der
betroffenen Software als Treiber direkt auf dem Volume werkelt.
Der Auslöser sind einmal der Finder, in dem man die Dateinamen kopiert,
und im anderen Fall PDF-lesende-Software wie Vorschau und Acrobat, die
den Text kopieren.
In meinem Fall ist es ganz offensichtlich die Unfähigkeit von
TextWrangler, mit der alternativen (völlig korrektem) UTF Variante
umzugehen, was ich auch daran sehe, daß TextWrangler komplett daran
scheitert, eine .txt Datei mit Inhalt hex 75 CC 88 55 CC 88 korrekt zu
öffnen. Was verwunderlich ist, da solche Geschichten (Reparatur von
Encodings) eigentlich mit zu seinen Kernkompetemzen gehört. Und der
Fehler hat nichts mit der Zwischenablage zu tun, er kann es einfach
nicht. Warum es früher ging... entweder TW hat es verlernt, oder der
Finder hat früher beim Kopieren normalisiert und jetzt nicht mehr.
Eventuell schicke ich denen nochmal diese .txt Datei, aber beim ersten
Bug-Report klangen die doch ein wenig patzig und abwimmelnd, kann also
sein, daß sie bei selten (und aus Ländern mit diakritischem Gedoehns :-)
gemeldeten Phänomenen bei einer Gratis-Software nicht wirklich Alarm
machen wollen...
In jedem Fall vielen Dank an Dich für Deine Erklärungen, mit dem (durch
Deine Infos) jetzt doch noch funktionierendem AppleScript hab ich einen
einfachen Workaround.
> Zum Thema HFS+ Dateinamen noch dieser Link:
> <https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties>
>
> Was dort verwendet wird ist weder NFC noch NFD nach aktueller Norm, d.h.
> ein Treiber der auf dieses Dateisystem schreiben möchte braucht
> spezielle Routinen zur Normalisierung der Dateinamen.
betroffenen Software als Treiber direkt auf dem Volume werkelt.
Der Auslöser sind einmal der Finder, in dem man die Dateinamen kopiert,
und im anderen Fall PDF-lesende-Software wie Vorschau und Acrobat, die
den Text kopieren.
In meinem Fall ist es ganz offensichtlich die Unfähigkeit von
TextWrangler, mit der alternativen (völlig korrektem) UTF Variante
umzugehen, was ich auch daran sehe, daß TextWrangler komplett daran
scheitert, eine .txt Datei mit Inhalt hex 75 CC 88 55 CC 88 korrekt zu
öffnen. Was verwunderlich ist, da solche Geschichten (Reparatur von
Encodings) eigentlich mit zu seinen Kernkompetemzen gehört. Und der
Fehler hat nichts mit der Zwischenablage zu tun, er kann es einfach
nicht. Warum es früher ging... entweder TW hat es verlernt, oder der
Finder hat früher beim Kopieren normalisiert und jetzt nicht mehr.
Eventuell schicke ich denen nochmal diese .txt Datei, aber beim ersten
Bug-Report klangen die doch ein wenig patzig und abwimmelnd, kann also
sein, daß sie bei selten (und aus Ländern mit diakritischem Gedoehns :-)
gemeldeten Phänomenen bei einer Gratis-Software nicht wirklich Alarm
machen wollen...
In jedem Fall vielen Dank an Dich für Deine Erklärungen, mit dem (durch
Deine Infos) jetzt doch noch funktionierendem AppleScript hab ich einen
einfachen Workaround.
0 new messages