[Allegro] ͏̈

[Thomas Berger]

Lieber Herr Schleifenbaum,


Am 04.06.2012 09:00, schrieb Reinhold Schleifenbaum:
> Liebe Liste, lieber Herr Eversberg,
> 
> wie lässt sich "͏&#776"
> in ucodes.apt umsetzen ?

es handelt sich um den Versuch, die Tuettelchen nach ihrer /Funktion/
als Dieaerese bzw. Trema zu differenzieren (statt die Sprache der
entsprechenden Worte zu notieren, wie es Unicode eigentlich vorsieht).

Einfuegen von U+034F COMBINING GRAPHEME JOINER ist ein offizioeser
Weg, so eine funktionale Differenzierung kenntlich zu machen
< http://unicode.org/faq/char_combmark.html#18 >:

>>>
Implementations which need to distinguish the two for searching and sorting may
systematically maintain weighting distinctions. <a, umlaut> = <ä> can be treated
as equivalent to <a, e> for sorting purposes, while the tréma <a, CGJ, umlaut>
can be weighted as a secondary variant of <a> thus resulting in the desired
behavior for such systems. Existing collations which do not distinguish tréma
and umlaut in their data will continue to work exactly as they currently do,
since in default collation tables CGJ is ignored in weighting.
<<<

D.h. ***wenn*** man weiss, dass so codierte Daten hereinkommen, koennte man
a/o/u + CGJ + Trema  auf ä/ö/ü kontrahieren und alle a/o/u + Trema getrennt
lassen. Bzw. wenn man traditionell einen internen Zeichensatz mit zwei
verschiedenen Tremas gehabt hat, die einen Kombinationen auf das eine und
die anderen auf das andere umsetzen.

Der MAB-Zeichensatz differenzierte zwischen Umlaut und Trema und daher musste
das unbedingt auch mit Unicode-Methoden aufrecht erhalten werden. Ich habe
allerdings damals einen Dump von DNB-Daten analysiert und ueberwiegend
Fehlverwendungen festgestellt (d.h. die Tremata, die behaupteten keine Umlaute
zu sein, waren groesstenteils doch welche, als Gegenprobe auch noch alle
Datensaetze mit Umlauten auf heimliche Tremata durchzusehen war mir allerdings
zu muehsam ;-) und seitdem habe ich eine eigene Meinung zu dem Thema...

viele Gruesse
Thomas Berger