[Allegro] Gibt es DEN ULTIMATIVEN UTF-8-Font??

Bernhard Eversberg ev at biblio.tu-bs.de
Mi Feb 22 07:56:48 CET 2012


Am 22.02.2012 00:28, schrieb Heinrich Allers:
>
> Warum gibt es eigentlich keinen Font, der UTF-8-kodierte Zeichen
> durchgehend und ohne diese (durch charset-Einstellungen bestimmte)
> Segmentierung, die die charset-Umschaltungen erfordert, korrekt
> dazustellen in der Lage ist?
>
> Oder gibt es ihn doch, diesen Font?
>
Es gibt den Font, eben Arial Unicode MS. Das Problem ist aber nicht
der Font, sondern das Listenobjekt (Auswahlfeld und Indexanzeige) bzw.
das Eingabeobjekt (Schreibfeld und Formularfelder). Die können's nicht,
das korrekte, synchrone Anzeigen des gesamten Fonts. Sie können immer
nur eine definierte Teilmenge (einen character set) korrekt anzeigen.
Dazu nicht gehörige Zeichen kommen falsch raus.
Nur interessanterweise das Anzeigefeld, ein "RichEdit"-Objekt, kann's.
Es fand sich bei nochmaligem Suchen kein Ausweg aus dieser Kalamität.

Zum Hintergrund:
Das Microsoft-Entwicklungssystem VisualC++ kann zwar Unicode, aber nur
in der 2Byte-Variante. Jedes Zeichen hat dann intern 2 Byte, auch
die unteren ASCII-Zeichen. Notgedrungen müßte man unter dieser Option
dann auch 2 Byte je Zeichen speichern. Schlimmer noch, die String-
Funktionen wie z.B. strcpy(), strcmp() usw. usf. müssen dann alle
in der "wide character"-Version verwendet werden, d.h. überall
müßte man statt dessen  wstrcpy() bzw. wstrcmp() schreiben.
Die Masse der dadurch erzwungenen Änderungen ist leider prohibitiv,
und auch die Daten selbst wären betroffen, alte Datenbanken
würden's nicht mehr tun mit einer Unicode-Version. Beim Index ginge es
es aufgrund einiger interner Funktionen überhaupt nicht.
Nur UTF-8 kann also zum Einsatz kommen, aber a99 kann dafür nicht
in allen Einzelheiten angepaßt werden. Der Index immerhin schluckt's
und zeigt's unter a30 auch komplett an. Nur die semitischen Schriften
leider falschrum. Ächz.

B.E.




Mehr Informationen über die Mailingliste Allegro