[Allegro] Unicode (von Fwd: Re: .dat files)

[Thomas Berger]

Lieber Herr Allers, liebe Liste,

> Um meine vergleichende Einschaetzung der Loesungen "Fischer" und "Lehmann" zu resuemieren:
> 
> Fischer setzt das Standard-Instrumentarium ein (mit P- und Q-Tabellen und so), um eine dreistellige Zahl 
> von Zeichen im unteren Unicode-Bereich zu erschlagen, waehrend Lehmann ganz anders rangegangen 
> ist und damit die 5-stellige Zahl von Zeichen des CJK-Bereichs zu erschlagen in der Lage war. Was 
> Lehmann gewinnt durch seinen Ansatz, muss er freilich damit bezahlen, dass die Realisierung einer 
> nennenswerten Zahl von Zeichen im unteren Unicode-Bereich mit ziemlichen Anstrengungen verbunden 
> ist.

Ich selber habe vor vielen Jahren einen dritten Ansatz realisiert, der die
ebenfalls mit Verlautbarung 163 eingefuehrte Methode mit Entitaeten &nnn;
umgesetzt wurde. D.h. Ich kann jedes Unicode-Zeichen in den Daten halten,
Speicherung in der Datenbank erfolgte jedoch als ISO-8859-1, nicht als UTF-8.
Hintergrund war eine "normale" Anwendung, wo jedoch ab und zu, v.a. auch in
Fussnoten Originalschriftliches erfasst werden /musste/.

Die Anwendung beruhte ganz wesentlich darauf, dass ich die volle Unicode-
Datenbank in Form von allegro-Datensaetzen in die allegro-Anwendung
importiert hatte, so dass ich mit der VS-Technik fuer den gegebenen
Kontext (Indexierung, a99-Anzeige, Bearbeitung, Druckausgabe, XML-Ausgabe) aus
den &...;-Entitaeten jeweils die passend vorbereiteten Umcodierungen und
Ersatzdarstellungen durch allegro einsetzen lassen konnte.

Originalschriftliche, in a99 nutzbare Indexregister habe ich mit dieser Methode
natuerlich nicht bekommen und die Bearbeiter mussten sich Feld fuer Feld
bzw. Datensatz fuer Datensatz entscheiden, ob das a99-Schreibfeld ausreichte
(Verknuepfungen) oder sie in notepad als externem Editor (Copy & Paste) agieren
wollten.

Wie bekannt, besitzt allegro mehrere Unicode-"Methoden", aber jede davon
erfordert gewisse Eingriffe (Umstellung der Datenhaltung auf UTF-8 hier,
Aktivierung von "&" als VS-Steuerzeichen dort, also ebenfalls Umstellung
exisitierender Daten, da "&" zu escapen ist) und hat noch wenig ausgelotete
Konsequenzen (Verzicht auf gewisse Kategoriefolgezeichen etwa). Und
natuerlich bedeuten alle Unicode-Loesungen den Verzicht auf die speziell
Ostwest-codierten Zeichen (ich weiss nicht, ob das unbedingt zwingend ist,
aber das Ueberwinden dieses Privat-Standards ist m.E. ein sehr wichtiges
Ziel und "Unicode" daher auch interessant fuer jene, die mit dem
bisherigen Zeichenrepertoire im Prinzip auskommen).


> Langer Rede kurzer Sinn: Wenn Allegro (hier: a99) etwas beitragen koennte, um diese Grenzen der 
> genannten Loesungen weniger hemmend sein zu lassen, waere es schoen - aber mein Eindruck ist nach 
> wie vor, dass es das Fehlen eines universalen UTF-8- (oder Unicode-) Fonts ist, der schoenen 
> Allegro-a99-Loesungen im Wege steht, konkret: den Aufbau zeichensatzuebergreifender Register 
> ausschliesst - kurzum, dass das Defizit also weniger bei Allegro als beim von Microsoft bereitgestellten 
> Font-Management liegt.

Es ist wohl war, dass ein OpenType-Font nur 65536 Glyphen enthalten kann
(und darin u.U. auch nicht in Unicode codierte, aber fuer typographische
Zwecke notwendige Ligaturen und Varianten unterbringen muss), und der
Unicode-Standard hat 16 mal so viele Codepositionen und auch real inzwischen
mehr als 110.000 darstellbare Zeichen.

Allerdings gibt es auch keine universellen Unicode-Fonts, denn jemand, der
einen ansprechenden Font fuer kyrillisch entwickelt, oder einen uebergreifenden
fuer arabisch, Thai und Vietnamesisch wird dennoch davor zurueckschrecken,
den Font im gleichen Stil und Anspruch auf Linear B und Klingonisch auszuweiten
und auch Amharisch kommt vielleicht erst demnaechst, wenn der Font in seinem
aktuellen Umfang etwas Geld fuer die Weiterentwicklung eingespielt hat. Zudem
gibt es auch inhaltliche Probleme, der Artikel der englischen Wikipedia
< http://en.wikipedia.org/wiki/Unicode_font#Issues > drueckt das recht vornehm
aus: "This has implications for the idea that a single typeface can satisfy the
needs of all locales"

Die Loesung besteht darin, dass eine Anwendung wissen muss, in welchem
Skript (grob die Kombination von Sprache und Schriftsystem) das momentan
auszugebende Textfragment vorliegt und das dann auch "einstellt", wozu
die Auswahl eines geeigneten Fonts (OTF-Fonts deklarieren die von Ihnen
abgedeckten "scripts") gehoert, aber u.U. auch weitere, als "Locale"
bekannte Eigenschaften, wie etwa die Groesse des Leerraums zwischen
Anfuehrungszeichen und folgendem Text).

Es genuegt i.A. nicht, Unicode-codierte Zeichen irgendwie hintereinander
weg zu erfasse, auch die Maschine sollte wissen, dass es sich um
kyrillisch notiertes Serbokroatisch ("Serbisch") handelt.

Bibliotheksdaten notieren tradionell die ~Sprache~ codiert (global, und
auf die Vorlage bezogen) fuer Multiscript Records in MARC21 gibt es
immerhin fuer das universelle Unterfeld $6 eine ganz kleine Codetabelle,
die fuer ein konkretes Feld zwischen Skripten differenziert:

Code 	Script
(3 	Arabic
(B 	Latin
$1 	Chinese, Japanese, Korean
(N 	Cyrillic
(S 	Greek
(2 	Hebrew

< http://www.loc.gov/marc/bibliographic/ecbdcntf.html >

viele Gruesse
Thomas Berger