[Allegro] Frage zu P/Q-Tabelle

Di Sep 30 15:29:32 CEST 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

moderne Webbrowser sind nicht besonders modern, was den
Umgang mit normalisierten Unicode-Zeichen angeht. D.h.
eigentlich (man denke an Sortierungen und Identitaetsvergleich)
ist A + Umlaut die in mancherlei bessere Darstellung, die
Aequivalenzdarstellung als praekombiniertes Zeichen nur ein
Service. Reale Browser schaffen es m.W. nicht, einer Folge
Grundbuchstabe + Diakritikum anzusehen, dass sie hier einen
(aus aesthetischen Gruenden vorzuziehenden) praekombinierten
Glyphen vorraetig haben, man muss schon froh sein, wenn die
beiden Einzelzeichen halbwegs sinnvoll angeordnet werden und
nicht verrutschen oder sich vermengen...

Insofern ist es vorteilhaft, sowohl was Datenbanken in OSTWEST-
Codierung angeht als auch solche mit einer der beiden Formen von
Unicode-Codierung, getrennt erfasstes vor der Ausgabe zu
rekombinieren. Das geht z.B. mit globalen Ersetzungen (wobei
die im Fall von OSTWEST-Datenbanken etwas krumm zu notieren
sind, da sie erst nach der Akzentvertauschung greifen?) hat
aber gewisse Grenzen:

1. Globale Ersetzungen, die innerhalb des Zeichensatzes
   operieren, also etwa zwei OSTWEST-Zeichen zu einem anderen
   OSTWEST-Zeichen zusammenfassen, sind unproblematisch

2. Globale Ersetzungen in einen anderen Zeichensatz sind
   problematisch, denn jeder definierte Ersetzungsbefehl
   wird nacheinander abgearbeitet, Ergebnisse frueherer
   Ersetzungen werden also weiteren Ersetzungen unterzogen.
   Es geht, wenn der Zielzeichensatz mit Escapes arbeitet,
   d.h. OSTWEST->7bit-ASCII mit HTML/XML-Parameterentitaeten
   ist ein Klacks, OSTWEST nach UTF-8 ist eher nicht moeglich.
   Nachteil ist ausserdem, dass die eigentliche Parameterdatei
   auf teilaufbereiteten Zeichenketten operiert, "ā" kann
   ich noch schlechter als "Makron + a" ansehen, ob die
   Zeichenkette mit einem Buchstaben beginnt...

3. Lokale Ersetzungen helfen aus dem bei 2. beschriebenen
   Problem mit der Teilaufbereitung, erfordern aber, dass die
   fragliche Parameterdatei jegliche Ausgabe in/an ein
   spezialisiertes Unterprogramm schickt, das dann die Ersetzungen
   vornimmt. Vorhandene Parameterdateien muessten dafuer sehr
   massiv umgearbeitet werden.
[Ein Spezialabschnitt "Parametrierte Ausgabe" analog den "dow w"-
Konstruktionen der Flexsprache waere ein Desiderat: Hier koennten
dann nicht nur Zeichenumsetzungen vorgenommen werden, sondern auch
andere Untersuchungen des Ausgabetexts, etwa ob eine URL drin
vorkommt und mit Markup versehen werden sollte etc.]

Ich habe nun festgestellt, dass die P/Q-Tabellen, die ja eigentlich
fuer nach "Verfahren 2" (also intern UTF-8) codierte Datenbanken
eingefuehrt wurden, fuer den obigen Zweck, also moeglichst spaete
Durchfuehrung recht allgemeiner Ersetzungen, anscheinend brauchbar
sind:

P 208 117 "ū"

bringt (in der betreffenden Parameterdatei wurde keine Akzent-
vertauschung durchgefuehrt) die OSTWEST-Bytes Makron + U in
Avanti zu ū

Dazu habe ich nun folgende Fragen:

a) "208 117" ist mitnichten legales UTF-8 (es ist ja legales
   OSTWEST), die Ersetzung funktioniert aber dennoch. Bug oder
   Feature? D.h. behaelt sich allegro vor, in zukuenftigen Versionen
   Ersetzungsbefehle, die kein valides UTF-8 enthalten, als
   Fehler zu quittieren bzw. zu verwerfen?
   [Das Handbuch 10.2.4.7 spricht recht vage von "Kombinationen
   von 2 bzw. 3 Zeichen", gemeint sind aber gerade keine Zeichen!]

b) In UTF-8 ist immer klar, wo ein Zeichen anfaengt und ob ein
   Byte ein Zeichen bzw. ein Zeichenanfang oder im inneren einer
   Bytesequenz vorkommt. Dementsprechend - wenn man P/Q-Tabellen
   fuer einzelne UTF-8-Zeichen nutzt, gibt es immer maximal einen
   Eintrag, der als Ausgangspunkt der Ersetzung zutreffend ist.
   Nutzt man es hingegen fuer Kontraktionen, wird die Reihenfolge
   wichtig (ich gehe mal davon aus, dass anders als bei p/q keine
   Ersetzungsmatrix aufgebaut wird, sondern eine sequentielle
   Abarbeitung erfolgt): Werden P/Q-Tabellen so wie eingegeben
   abgearbeitet oder aus Effizienzgruenden durchsortiert?

c) unicode.rtf sagt, "Wenn kein P/Q-Befehl greift, treten die
   p/q-Befehle in Kraft." Das ist nicht falsch, legt aber
   ein Missverstaendnis nahe, naemlich dass dieser Satz eine
   Information enthaelt, insbesondere zum Verhalten beim "Greifen"
   von P/Q-Befehlen. (codier.rtf hingegen enthaelt die wichtige
   Information "Die P/Q-Befehle haben Priorität vor den p/q-Befehlen,
   d.h. sie werden beim Abarbeiten einer Exportzeile zuerst ausgeführt."
   wobei der Nachsatz nahelegt, dass p/q-Befehle ausgefuehrt werden.

   Experiment ergibt:

   Das Resultat von P/Q-Befehlen scheint normalen p/q-Codierungen
   nicht mehr unterworfen zu werden, wohl aber noch den Drucker-
   Ersatzdarstellungen.

   D.h. wenn ich

p & "&"
P 208 117 "ū"

habe, dann wird 208 117 zu ū gewandelt. Habe ich hingegen

p .38 .38 97 109 112 59
P 208 117 "ū"

dann kommt "u&#772;" heraus (ich finde das in Ordnung, weil
ich normalerweise stets noch ein unbenutztes Zeichen einsetze,
um nackte "&"-Zeichen zu erzeugen, d.h. ich habe sowieso

p .14 .38
p .38 .38 97 109 112 59

und setze dann

P 208 117 "u♫#772;"

   Jedenfalls: Man kann argumentieren, dass sowohl unicode.rtf als
   auch codier.rtf im Sinne der Aussagenlogik korrekt sind, "ex
   falso sequitur quod libet" haben wir ja schliesslich alle
   gelernt, und wenn etwas "zuerst ausgefuehrt wird" heisst das
   noch lange nicht, dass etwas anderes als zweites ausgefuehrt
   wird. Beide Dokumentationstexte schreien allerdings danach,
   missverstanden zu werden, hier muss etwas passieren. Und
   bezueglich des wie ueblich feinen Unterschieds zwischen
   Umcodierungen und Drucker-Ersatzdarstellungen wird ja nichts
   dokumentiert.

d) unicode.rtf gibt als Syntax
>>>
P zzz yyy xxx abc
  mit zzz yyy xxx = Dezimalcodes des UTF-8-Zeichenwertes
        abc = Was dafür einzusetzen ist (direkte Zeichen)
  Alternativ:
P xyz abc
   mit  xyz = direkte UTF-8-Zeichen
<<<

  Ich habe allerdings (nicht ganz die frischeste) Avanti-Version
  damit Probleme gehabt. Sprich

P Ðu ū
bzw.
P 208 117 ū

  funktionierten nicht (und zwar beim ersten Datensatz anders
  "nicht" als beim zweiten im gleichen Export), Umschliessen
  des Ersetzungsstrings mit "...", also

P Ðu "ū"
bzw.
P 208 117 "ū"

  funktioniert anstandslos. Wie ist die Syntax fuer die P/Q-Tabelle
  nun genau?

e) unicode.rtf spricht von zwei- bzw. drei-Byte-Kombinationen fuer
   die UTF-8-Zeichen. Vierbyte-Kombinationen gibt es in Unicode aber
   durchaus auch, zumindest seit Unicode 4.irgendwas (aktuell
   5.irgendwas): Gibt es da noch etwas zu beachten, wenn ja, fuer wen
   (Anwenderfalle bzw. Handlungsbedarf fuer die Entwicklungsabteilung?)

f) das (a99-"online") Handbuch verweist in Kapitel 10.2.4.7 nur
   unspezifisch auf http://www.allegro-c.de/ (wo man dann wohl
   unter "Ruckzuck" zu schauen haette, wie das mit P/Q-Funktioniert.
   Das ist nicht so guenstig.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSOIpvGITJZieluOzAQI3iQQAosrEC6QYNo3lEC4ZcwildO/2E5BxCFNO
hyHGkLQxvHOrwGrzJaAOXP9i+RcHXnAQPm6w/fRiSpSmdj7qPFVaFSJL4GyaAutg
AIXRMOIJEfimHoUvluL38BPC0toTF7R1pGF+lV6ZR71rcRGKJPN5BUpHpM9pAwq1
cSvE2clTxmQ=
=zr38
-----END PGP SIGNATURE-----