[Allegro] Import und Unicode

[Bernhard Eversberg]

Uns treibt um, daß beim Import die Umwandlung von Unicode in den
Interncode nicht absolut glücklich gelöst ist.

Es funktioniert so:
Wenn in den Exportparametern u-Befehle eingebaut sind, z.B.
mittels des Befehls

tucodes

die Liste ucodes.apt inkludiert wird, dann werden diese Befehle
automatisch ausgeführt, und zwar jedesmal am Ende eines Paragraphen.
Sagen wir, es steht geschrieben:

#20
s 0 "4000 "
...  evtl. Manipulationsbefehle

in einer  pica.aim  oder so, dann wird der Fremdsatz nach der
angegebenen Sequenz durchsucht und der gefundene Inhalt nach
Abarbeitung der M-Befehle durch die u-Liste gejagt, also jeder
darin stehende UTF-8-Code ersetzt durch das dazu angegebene
interne Codezeichen. Beispiel: Wenn in der u-Liste steht:

u 195 164 132    ...

dann wird in besagtem Inhalt überall die Kombination  195 164 gewandelt
in das DOS-ä.

Was nun aber, und darum geht's uns, wenn hernach diese Paragraphen
kommen:

#39
k20
b" / "

#20
k20
e " / "

um den Inhalt von #20 nochmal zu zerlegen in #20 und #39?

Das macht meistens kein Problem, aber es macht genau dann eines,
wenn in dem umgewandelten Text von #20 ein Code oberhalb 191 vorkommt.
Wie z.B. der Code 225  für das scharfe s.
Denn alle UTF-Codes sind solche, und wenn einer davon nicht in
der Liste steht, wird eine Sequenz der Gestalt  &#nnn;  draus
gemacht (nnn = dezimale Unicode-Nummer) , unter Hinzunahme des einen
oder der zwei nachfolgenden Codes, was in diesen Fällen immer falsch
ist.

Was also tun?
Auch hier geht es darum, wie so oft, einen Bruch der Kontinuität
zu vermeiden, damit alte Parameter dann nicht versagen,
Zwei Ansätze drängen sich auf:

1.
Wir haben erst gedacht, die Lösung könnte ganz einfach so aussehen,
daß das Programm den gesamten Fremdtext direkt nach dem Einlesen
umwandelt, so daß bei den einzelnen Feldern dann nichts mehr
zu tun ist in der Hinsicht, der oben beschriebene Vorgang also
entfällt. Was aber, wenn dann in einem Paragraphen ein s-Befehl
oder auch ein b-Befehl eine Unicode-Sequenz sucht, z.B.

#47
s "Übersetzer: "

wobei dann bisher das Ü eben ein Unicode-Ü zu sein hätte, nach der
genannten Änderung aber ein DOS-Ü, d.h. der s-Befehl tät's nicht mehr.

2.
Ein anderer Weg, gleichfalls naheliegend und wie wir jetzt denken
besser, wäre:
Wenn in einem Paragraphen mit einen k-Befehl ein Inhalt eines anderen,
schon umgewandelten Felds herangezogen wird, dann entfällt die
automatische u-Wandlung des Inhalts.
Auch hier sind aber Problemfälle denkbar, etwa sowas wie dieses:

#123
s "ABC: "
k345
w" / "

Dann würde das, was im Fremdtext hinter "ABC: " steht, nicht
umgewandelt, weil ja dann noch ein k-Befehl kommt und die
Umwandlung erst am Ende des Paragraphen stattfindet.

Was wäre besser, 1. oder 2.? Vielleicht ist das unter 1.
genannte Problem sehr viel seltener zu erwarten?

Nachwort
Im Prinzip recht, aber nur im Prinzip, hätten jetzt die, die
nun sagen wollten, "Ja Himmelherrgott, stellt endlich alles um
auf Unicode, dann brauchen wir über solche Quisquilien kein
Wort mehr zu verlieren."
Denn erstens ist hier eine 100%-Lösung momentan unrealistisch,
zweitens wollen wir ja eine Konfiguration mit internem UTF-8
noch erstellen (ansatzweise ist sie schon da und auch unter
a35 schon einsatzfähig und mit im a35-Paket drin), und drittens - falls
einem das nicht weit genug geht - sind die Quellen offen und jedem
anheimgestellt, sein Können zu erproben oder, viertens, ein neues
System mit 100% Unicode aus dem Boden zu stampfen. Was wir uns,
zugegeben, nicht zutrauen oder nicht versuchen wollen, denn vielleicht
kommt sowas schon morgen oder bald heraus, z.B. unter dem Namen
Kuali oder als nächste Version von Koha oder als cloudbasierte
Endlösung für alle und alles.
Aber das nur nebenbei.

B.E.