[Allegro] Unicode-Variante der Standardparameter i.Vb.

[Thomas Berger]

Lieber Herr Eversberg,

> Auf unserer Agenda2015 steht noch die Verbesserung der Unicode-
> Parametrierung.
> Schon ca. 2002/03 hatten wir die ersten Ansätze gemacht, dann hat
> die Sache lange Zeit geruht - es war geringe Nachfrage. Spezialanwender

So wuerde ich das nicht interpretieren: Schon Jahre vorher war
gefragt worden, wie etwa griechische Zitate in Sachtiteln oder
Fussnoten zu behandeln waeren.

Wenn ich mich recht entsinne, wurden 2003 zwei, miteinander nicht
kompatible Methoden eingefuehrt, beide erforderten Aenderung der
vorhandenen Daten und Parameter und die Entwicklungsabteilung
mochte sich nicht festlegen, welche Methode die einmal empfohlene
werden koennte.



> Mit a99 wird man zwar arbeiten können! Aber im Auswahlfenster, im
> Schreibfeld und in den Formularen *kann* nun mal Unicode nicht
> präsentiert werden. Da können wir nichts dafür, das liegt an internen
> MicroSoft-Problematiken. Nachbohren zwecklos, es geht nicht.
> Nur das externe Editieren ist dann auf Windows-Ebene komplett in
> Unicode möglich, mit Notepad, WInVi o.a. Die Register blenden die
> Diakritika aus, sind also unproblematisch, das Anzeigefeld wird in den
> RTF-Unicode-Modus geschaltet und zeigt dann alles korrekt. Alle

Bislang gab es auch stets kleinere Verluste beim Copy&Paste von
anderen Anwendungen ins Schreibfeld von a99 - Windows weiss ja
sehr gut, welche Fenster 8bittig sind und welche nicht, und
konvertiert die Daten aus der Zwischenablage entsprechend. Bei,
den Zeichen, bei denen es Unterschiede zwischen allegro-Windows
und CP1252 gibt, geht und ging das schief. Eine intern mit
Unicode arbeitende Datenbank wird den OSTWEST-Font nicht benoetigen,
die Moeglichkeit zum Copy&Paste wird dadurch zunaechst einmal
verbessert. Wuesste a99 nun, dass es mit UTF8-codierten Daten
arbeitet, koennte die ohnehin stattfindende Konversion "Windows"
-> "allegro" fuer Schreibfeld-Eingaben das beruecksichtigen und
zumindest fuer Normaltexte von Normalanwendern meistens das richtige
tun (also ein "ä" in UTF-8 wandeln).

Besonderes Augenmerk wird man bei dieser Variante (Schreibfeld
operiert mit CP1252) der Eingabe von Steuerzeichen widmen
muessen, also Unterfeld-Dreieck, Nichtsortierzeichen und den
diversen "¶" oder "►", die einige Anwendungen als zusaetzliche
Steuerzeichen definieren: Die sind dann u.U. nicht mehr ueber
Tastenkombinationen eingebbar und es muss ein *offizieller*
Ersatzmechanismus eingefuehrt werden.

Es wurde gestern schon von Herrn Fischer angsprochen: disphead.rtf
und Kollegen sind ein Nadeloehr, da sie zentral fuer alle Datenbanken
der Installation gelten. Auch hier muesste a99, wenn es /weiss/,
dass intern UTF-8 vorliegt, eigentlich von sich aus auf einen
alternativen Satz von RTF-Header-Fragmenten umschalten.


> Und um jedweder Verunsicherung entgegenzuwirken:
> Wem jetzt der Kopf schwirrt, kann auch, falls kein zwingender Bedarf
> vorhanden ist für mehr fremde Zeichen als bisher, bei a99 mit der
> jetzt üblichen OstWest-Codierung bleiben. Die Fremddaten von DNB und
> GBV kommen zwar in Unicode an, werden aber nach OstWest gewandelt,
> an dieser Stelle wird's weiterhin keine Probleme geben. Und V36 usw.

an dieser Stelle werden die Probleme weiter wachsen: Anfangs wurde
den Austauschformaten MAB und MARC21 nur ein Code spendiert, um
"UTF8-codierte Daten" zu deklarieren, das /Repertoire/ der Zeichen
blieb aber dasjenige, das von den "offiziellen" Zeichensaetzen
abgedeckt wurde (und das ist bei MARC21 im Prinzip sehr viel, weil
durch einen Umschaltmechanismus auch lange vor Unicode
originalschriftliche Katalogisierung moeglich war - keine Ahnung,
welche Systeme das unterstuetzten, der Standard sah es vor). Fuer
MAB war das Repertoire nicht besonders gross und entsprach in etwa
den Anforderungen an "bibliothekarische Zeichensaetze DIN 31628 Stufe
2"

Peu a Peu wurden dann Datenbestaende auf interne Speicherung in Unicode
umgestellt, parallel dazu wurden in MARC21 und nachvollziehend in MAB
unspezifische Sammelfelder fuer Originalschrift eingefuehrt (d.h.
wenn ich einen Inhalt sowohl romanisiert/transliteriert als auch
originalschriftlich erfassen will, dann trage ich eine Form in das
dafuer im Datenformat vorgesehene ein, die andere in ein Feld aus
diesem Sammelpool und verklammere die miteinander). Will man solche
Daten transportieren, wird natuerlich das ISO-5426 Repertoire
gesprengt und z.B. die DNB hat schon vor Jahren angekuendigt, ueber
ihre Schnittstellen das volle Unicode-Repertoire auszuliefern.


> werden in dieser Hinsicht auch nicht anders funktionieren und mit
> Ihren Daten im Jetztzustand unverändert funktionieren. Einen *Zwang*
> zum Übergang auf Unicode intern wird's, anders gesagt, auch künftig
> *nicht* geben. Und wenn Ihr Admin mal plötzlich eine exportierte

Eine der Unicode-Methoden war ja relativ unintrusiv und beruhte darauf,
dass "&" zum Steuerzeichen wird, so dass einzelne Unicdode-Zeichen oder
-Worte wie in SGML/HTML/XML als Ӓ gespeichert werden koennen.
"Nackte" Zeichen "&" in den Daten muessen dabei allerdings als "&"
escaped werden, das ist die Kroete dabei. Allerdings ist - genau wie
alle Webbrowser - allegro inzwischen recht tolerant, d.h. ein isoliertes
"&", das weder als "&" noch als "&#nnnn;" fortgesetzt werde, fuehrt
nicht zu Beschimpfungen des Anwenders, sondern wird stillschweigend
als "&" interpretiert.

Eigentlich koennte man ueberlegen, diesen Unicode-Modus als Default
in den Standardparametern einzustellen (wer es nicht will, weil in
den Daten zu viele URLs mit krummen "&" sind, kann es abschalten),
die meisten Importroutinen sind ja so einstellbar, "unbekannte" Unicode-
Zeichen auf diese Form umzustellen, nur mit der Akzentvertauschung
mag es dann hapern. (Mit "ueberlegen" meine ich tatsaechlich ueberlegen,
es waere nuetzlich zu wissen, an welchen Stellen es dabei noch hapert
und ob das geglaettet werden kann).

[Ich selber habe 2008 eine Anwendung gebaut, die mit Ruecksicht auf den
Wunsch der Bearbeiter, auch mit PRESTO zugreifen zu koennen, diese
Unicode-Methode mit "&"-Escapes genutzt hat, aber intern nicht mit
Ostwest, sondern mit CP850 gearbeitet hat. Originalschriftliches
liess sich dann auch hier nur ueber "externes editieren" mit notepad
bearbeiten (also insbesondere nicht mit PRESTO ;-), onextern.flx
wurde entsprechend geaendert, ein vorbereitender Export hat mittels
VS-Ersetzungen die Parameterentitaeten &#....; in UTF-8 umgewandelt
(heute geht es m.E. auch etwas effizienter), so dass in Notepad
*Zeichen* erschienen und bearbeitet werden konnten. Der Rueckweg
der Daten ist hingegen von der Flex-Sprache gut unterstuetzt, man
gibt (in onextern.flx, vgl. utfedit.flx)

set U1
insert
set U0

und fertig... Problematisch hier wiederum die z.B. in notepad nicht
als solche darstellbaren (und erst recht nicht eingebbaren)
Steuerzeichen, insbesondere die diversen Dreiecke - das Problem haben
aber alle Bibliothekssysteme, und es gibt da mindestens so viele
Loesungen wie es Bibliothekssysteme gibt, z.b. "|" oder "$" oder
"\\$" ...

viele Gruesse
Thomas Berger