Bloss eine Idee

[Thomas Berger]

Lieber Herr Hoeppner,

> nichts. Um das zu umgehen müßte man tricksen. Was aber schon
> mal testweise gemacht wurde ist, UTF-8 zu speichern und
> auszugeben. Dort sind die Unicopde-Zeichen etwas ander
> gespeichert. Es war eine Anbindung einer sinologischen Datenbank
> ans Web oder zumindest der Versuch. Zu sehen gab's erstmal nix.
> Auf meinem Windows-Rechner fehlte nämlich der komplette
> Zeichesatz (NT!) Also das erste Problem, ohne Zeichensatz nix los -
> > Download von etlichen zig-Megabytes abgesehen davon, dass ich
> erstmal nach einem freien Zeichensatz suchen mußte. Die sind
> normalerweise recht teuer. Also obwohl die Zeichen da waren,
> konnte ich zunächst nichts sehen. Auch IE würde bei korrekten
> XML-Daten scheitern, wenn er den Zeichesatz nicht hätte. XML
> oder nicht. Und dann müßte das Programm auch in div.
> Schreibrichtungen schreiben können. Wenn diese Fähigkeit fehlt,
> gibt es nur Schrott zu sehen. Aber vielleicht könnte der IE das ja,
> weiss ich nicht.

vermutlich der am ehesten. Ich habe auch schon einmal 
beobachtet, dass mir der IE5 automatisch einen Zeichensatz
zum Download angeboten hat, da war ich dann ziemlich baff.
Jedenfalls sind die von Ihnen angesprochenen Probleme 
natuerlich Probleme in dem Sinne, dass die Unicode-
Unterstuetzung derzeit ueberall ziemlich lausig ist und
dass es wenig freie Zeichensaetze gibt. Es sind aber
keine spezifischen XML-Probleme oder so, schliesslich
sind die Alternativen (chin. Zeichensaetze ohne Unicode)
ja auch nicht kostenlos.

Fuer den vom Ostwest-Zeichensatz abgedeckten Bereich
gibt es einen Haufen Fonts, insbesondere auch Times Roman
etc. Hier ist eher das Problem, dass das RichEdit-Element,
das die Anzeige unter a99 und alcarta regelt, mit
Unicode nichts anfangen kann. Das normale Edit-Element
fuer die Eingabe hingegen muesste Unicode koennen, 
vermutlich aber nur unter NT, nicht unter Win'9x :-(

UTF-8 ist vermutlich der vernuenftigste Weg (und zufaellig
auch der von XML) um allegro UNICODE-faehig zu machen.
In dieser Codierung kann man immer absolut zuverlaessig
feststellen, ob ein Zeichen anfaengt oder nicht, ausserdem
ist immer klar, wieviele Bytes zu dem gerade kommenden
Zeichen gehoeren. Fuer den Start wuerde es auch ausreichen,
Zeichenumwandlugs-Listen (statt der Tabellen) fuer lateinische
Alphabete vorzubereiten (Indexierung: Reduktion auf Grundbuchstaben
und Kleinschrift-Form, Umwandlung fuer Ostwest-Anzeige unter
DOS, "allegro"-Anzeige unter Windows), das ist kein Aufwand,
wenn die internen Strukturen erst einmal da sind.


> Wo wir aber definitv etwas machen müßten, wären Erweiterungen in
> der Exportparametrierung, oder Ersatz durch etwas anderes, denn
> z.B. die Umcodierungtabellen können nur max. 256 Zeichen
> aufnehmen. Mehrbytige Zeichen gehen nicht. Und die DOS-
> Programme könnten dann gar nicht mehr richtig mit der Datenbank
> arbeiten :-((

verstehe ich nicht: Das, was man bislang mit DOS-Datenbanken
und OSTWEST-Font (bzw. den sinologischen zweibyte-Konventionen)
mach konnte, wird man auch weiterhin machen koennen.

Ist auf dem Expertentreffen eigentlich ein Eckchen fuer
Unicode freigehalten?

viele Gruesse
Thomas Berger