[Allegro] Vb.263: V34.6 ist da

[Thomas Berger]

Liebe Liste,

Am 02.09.2014 um 15:24 schrieb Bernhard Eversberg:

> Phrasenspeicher erweitert - Mehr globale Ersetzungen beim Export
> ----------------------------------------------------------------
> 
> Es hatte sich gezeigt, daß es beim Export schon mal eine Knappheit
> geben kann: Beim Umwandeln von UTF-8 nach ASCII oder ANSI fallen die-
> jenigen Codierungen unangenehm auf, die aus einem Grundbuchstaben plus
> nachgestelltem Diakritikum bestehen: Statt des Zeichens ä kann man in
> UTF-8 auch ein a schreiben und das Sonderzeichen "Trema" (im Unicode-
> Jargon "diaeresis" genannt) direkt dahinter (statt davor, wie wir es
> von alters her gewohnt sind). Konkreter:
> 97 204 136   a + "COMBINING DIAERESIS" ==>  97 189  im OSTWEST-Code
>  statt
> 195 164      ä ==>  132  im OSTWEST-Code
> 
> Zwar können wir mit dem Befehl
> 
> pa=181 182 183 184 189 190 198 199 207 208 209 210 211 212 219 222 223 232
> 
> die Akzentzeichen vorgeben und dann mit #da die Vertauschung von
> a<akzent> in <akzent>a veranlassen, aber aber wir würden doch gern
> aus a<Trema> nicht <Trema>a machen, sondern ä. Für den Zweck bleibt nur
> die Funktion "Globale Ersetzung":
> 
> _\189a_ä_

... oder auch lokale Ersetzungen ...


> Eine Liste solcher Befehle für die gängigen Zeichen hat T. Berger in
> einer Datei  utfkombi.apt  mit extremer Akribie zusammengestellt.
> (Er würde bescheiden sagen: mit dem Minimum der absolut notwendigen
> Akribie.) Hier ist die Datei:
> 
>    http://www.gymel.com/
> (Für den eiligen Leser: vom Programm verwendet werden nur die mit _
> beginnenden Zeilen, der Rest ist Kommentar.)

Da ist die Datei nicht, sondern in inst-all.exe

Sie ist wohl ein Klon von i-protyp.apt,
< http://svn.gymel.com/acxt/produkt/marcimpdir/i-protyp.apt >, die
ich zu Zeiten von Unicode 4.0 einmal aus maschinell generierten
Umsetzungstabellen erarbeitet habe: Die Aufgabe ist recht begrenzt:
*Nachdem* Zeichen ggfls. aus einem Fremdzeichensatz bereits nach
allegro-Ostwest umgesetzt worden sind, werden nachgelagert Grund-
buchstaben mit voranstehenden Diakritika ("Protypen" hiess das mal?)
zu kombinierten Zeichen zusammengezogen. Begrenzt ist die Aufgabe
deswegen, weil es in OSTWEST nur die beschraenkte (in der pa-Liste
aufgezaehlten) Menge von isolierten Diakritika gibt und die moeglichen
Kontraktionen sind durch die Anzahl kombinierter Zeichen in OSTWEST
vorgegeben und ebenfalls beschraenkt (das reflektiert den Stand
vor der Einfuehrung einer der Unicode-Methodiken in V23, die
mit &#nnnn; jegliche Unicode-Zeichen erlaubt).

[Warum Herr Eversberg seine Version utfkombi.apt genannt hat,
wissen nur die Goetter: Es handelte sich bei i-protyp.apt um
Ersetzungen, die in OSTWEST codierte Daten in immer noch OSTWEST
codierte Daten umwandeln. Ich sehe aber gerade, dass utfkombi.apt
die Akzente noch Unicode-maessig /hinter/ den Grundbuchstaben
erwartet, also Eingangsdaten, die noch nicht ganz OSTWEST
vorliegen. Einsatzbereich von utfkombi.apt ist i-gnd.apr, die
wohl fuer diesen Zweck nur von import.exe genutzt werden darf,
nicht bei normalen Exporten - in Bezug auf Zeitpunkt und Richtung
der Akzentvertauschung in Exportparameterdateien unterscheidet
sich import.exe stark vom "bekannten" Verhalten beim Export...]


Die Datei ist mit 72 Ersetzungsbefehlen auch nicht besonders
ressourcenhungrig (jedenfalls ist mir das 2001 nicht so
aufgefallen, da waren es aber immer nur 16bit-Module).

Die Ersetzungen in der Datei sind als "*import" dann auch noch
einmal auskommentiert in der viel kompakteren Syntax der "Protyp-
Ersetzungen" in Importparametern vorgehalten, in der Praxis kommt
man meiner Erfahrung nach aber nicht immer mit einer reinen
Import-Loesung hin: So muss man etwa bei Fremddaten mit ISO2709-
Directory darauf achten, Zeichen nicht so zu konvertieren, dass
sich Feldpositionen oder -laengen aendern, oder bei Unicode-Daten
sind ja nicht nur die Zeichen umzusetzen und zu kontrahieren,
sondern zwischendurch hat noch die (umgekehrte) Akzentvertauschung
stattzufinden...



> Spürbar relevant wurde die Sache, als sich zeigte, daß es in den ZDB-
> Daten große Mengen solcher Codes gibt.

Mir liegt hier ein Halbjahresabzug fuer eine Bibliothek vom letzten
Herbst vor, 1308XXXXzdbtitutf8.mrc. Da liegen die Zeichen tatsaechlich
in NFD (Canoincal Decomposition) vor [siehe Unicode Standard Annex #15 dazu,
< http://www.unicode.org/reports/tr15/tr15-41.html >]. Mit "solche Codes"
meinen Sie dann UTF-8 codierte Daten mit isolierten Diakritika?
Das ist ja eigentlich nichts neues, sowohl im MAB- als auch im MARC8-
Zeichensatz gab es gar keine praekombinierten Zeichen (ausser den
"stroked" Buchstaben und der sz-Ligatur). Und ob man das Zusammenfassen
will, ist eine Frage, die man sich regelmaessig neu stellen sollte:

* Will man in allegro Umlaute und Doppelakute als "ae" etc. sortieren
  lassen (so wie von RAK gefordert), dann geht das am praktischsten
  mit den p/q-Tabellen der Exportsprache, erfordert also eine
  Zusammenfassung - fuer diese beiden speziellen Akzente.

* Liegen Zeichen in Fremddaten praekombiniert vor, muss der Import
  alle einzeln "kennen" und verarbeiten: Das sind viel mehr verschiedene
  als in der dekomponierten Form vorliegen koennen, und dort kann
  man dann alle unbekannten/unbeherrschten ausfiltern. Hauptproblem
  bei praekombinierten Zeichen ist aber, wenn im Zielzeichensatz
  OSTWEST eben keine Praekombination existiert und der Import dann
  wirklich die kombinierte Form in Akzent plus Grundbuchstabe
  umwandeln muss - fuer jede moegliche kombinierte Form, von denen
  Jahr fuer Jahr neue hinzukommen...

* Seit Computer intern ohnehin mit Unicode arbeiten, ist es etwa
  fuer Internetbrowser keine besondere Hexerei mehr, dekomponiert
  vorliegende Zeichen im Quelltext geeignet zusammenzufassen und
  ein praekombiniertes Zeichen aus dem eingestellten Font darzustellen

* Generalisieren laesst sich das nicht unbedingt, ich musste letztens
  eine Anwendung von XeTeX auf LuaTeX umstellen (beides im Prinzip
  UTF-8 beherrschende Nachfolger von PDFTeX), da sah es dann aber
  sehr unschoen aus und ich musste die Quelltexte vorab auf NFC trimmen.

perl -MUnicode::Normalize -ne "print NFC($_)" infile > outfile


viele Gruesse
Thomas Berger