unicode

[Bernhard Eversberg]

Herr Teschke hat die wohlbegruendete Frage, 

> ... ob die
> Aussicht besteht, dass Allegro eines Tages unicodefaehig wird.

Wann dieser Tag sein wird, wenn er denn kommt, kann jetzt noch in keiner
Weise beantwortet werden.
Dass andere Software damit umgehen kann, heisst noch nicht, dass man es
mehr oder weniger leicht realisieren kann. Man muss auch schauen, WAS denn 
im Einzelnen diese andere Software mit den Codes machen kann und was nicht.
Eines der ganz grossen Probleme sehen wir in der Indexierung. Die Tabellen
dafuer sind jetzt sehr kompakt, bei UNICODE wuerden sie sich gewaltig
aufblaehen muessen, was u.a. eine enorme Fleissarbeit voraussetzen wuerde,
sie erst einmal zu erstellen.
Zweitens, die Zunahme des Umfangs der Daten. Nicht jeder wird eine
Verdoppelung des Volumens hinnehmen wollen, nur weil ganz gelegentlich mal
ein Sonderzeichen vorkommt - die weitaus meisten Anwender haben keine
Ostasiatica. Wir muessten dann also zwei Versionen pflegen.
Es hat also gar keinen Sinn, hier bereits irgendwelchen Optimismus zu
verbreiten.

Ergaenzend aber folgende Fragen:
Wie sieht denn das konkret in den Daten aus, wenn ein Umlaut vorkommt?
Koennen Sie uns Beispieldaten zukommen lassen? Vielleicht muss ja nur die
Methodik der Anwendung der o-Tabelle modifiziert werden, wie es ja 
schon bei den p- und q-Befehlen einwandfrei funktioniert. Ist es nicht so:
wenn ein Code oberhalb 160 vorkommt, bildet er zusammen mit dem naechsten
Byte ein chinesisches Zeichen? Oder muessen zwei aufeinanderfolgende Bytes
oberhalb 160 liegen, um chinesisch interpretiert zu werden (sonst wuerden
ja die Umlautcodes sowieso nicht funktionieren - oder wie sind die wirklich
dann codiert?)
Wenn sich in diesem Bereich was machen liesse, waere der Aufwand 99%
geringer, als wenn man auf Unicode hinwirken wuerde!
MfG B.E.

Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, 
D-38023 Braunschweig, Germany
Tel.  +49 531 391-5026 , -5011 , FAX  -5836
e-mail  B.Eversberg at tu-bs.de