[Allegro] Frage zu P/Q-Tabelle

[Bernhard Eversberg]

Zu Bergers Fragen erst einmal, vorbehaltlich weiter Ausfuehrungen,
auf die Schnelle ein paar Hinweise betr. die anscheinend wichtigsten
Unklarheiten:

> 
> 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?
Nein. Validitätsprüfung wäre ja auch recht aufwendig.

>    [Das Handbuch 10.2.4.7 spricht recht vage von "Kombinationen
>    von 2 bzw. 3 Zeichen", gemeint sind aber gerade keine Zeichen!]
Nein, Bytes.
> 
> 
> 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?
> 
wie eingegeben.

> c) unicode.rtf sagt, "Wenn kein P/Q-Befehl greift, treten die
>    p/q-Befehle in Kraft." 

Das ist so gemeint: Ein Byte x oberhalb 127 loest Pruefung der P-Codes
aus, in der gegebenen Reihenfolge der P-Zeilen.
--  Bei Uebereinstimmung wird x mit dem oder den nachfolgenden Bytes
ersetzt durch die Werte der P- bzw. Q-Zeile. Die so zugeordneten
Zeichen werden keiner weiteren Prüfung/Umwandlung per p/q unterzogen.
--  Bei Nichtübereinstimmung wird x dann per p- bzw. q-Tabelle umcodiert.
Druckercodierungen sollte und kann man in den hier relevanten Fällen
vermeiden.


B.E.