[Allegro] v23 getestet

Do Jun 21 00:55:04 CEST 2007

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

Liebe Liste, lieber Herr Eversberg,

Bei all der Meckerei kommt die Arbeit oft zu kurz, daher kam ich erst
mit 4 Jahren Verzoegerung dazu, einige der Unicode-Methoden aus VB 164
auszuprobieren...

Eine alte Datenbank arbeitete mit einem eigenen Protypensystem, das auch
typographische Besonderheiten (verschiedene Sorten Anfuehrungszeichen
etc.) abbildete, insofern kam eine Umwandlung nach allegro-OSTWEST nicht
so recht infrage. Ich habe dann dankbar die Gelegenheit ergriffen, die
Daten in einen Grundzeichensatz plus numerische Unicode-Entitaeten (also
&#x0101; oder &#x257;) umzuwandeln.

Als Vorbereitung ist eigentlich nur erforderlich, literale "&" in den
Daten durch "&" zu ersetzen.

Als Basiszeichensatz habe ich dann CP850 gewaehlt, bzw. das Subset
davon, das unter der in Windows-Systemen automatisch gegebenen Abbildung
nach CP1252 in die Untermenge ISO-8859-1 abgebildet wird. Direktes
ISO-8859-1 waere eine Option gewesen, CP850 eroeffnet aber die Option,
auch weiterhin unter DOS arbeiten zu koennen. Allegro-OSTWEST
(Standardschema) oder Allegro-Windows (Neutralformat) habe ich bewusst
nicht in Betracht gezogen, ungehindertes Copy&Paste in/von dieser
Anwendung ist wichtig, und ich sehe keine Vorteile der allegro-eigenen
Zeichensatzverbiegungen, wenn man sowieso mit Unicode arbeitet.

Ich habe dann zunaechst aus der Unicode Character Database (das ist
eine Textdatei) knapp 18.000 Datensaetze fuer die "VS-Sequenzen" (oder
steht das "S" bereits fuer "Sequenz" gebildet:

#02 vs257
#VS 0101
#VS0196 129▼b─ü
#VS1LATIN SMALL LETTER A WITH MACRON
#VS2Ll▼c0▼bL▼mN
#VSD257
#VSEamacr
#VSK0061 0304
#VSM▼u0100▼l0100
#VSpa⌂
#VSr\u257\'61

#VSp ist die "Darstellung fuer p-Tabelle", ein moeglichst
gutes Mapping zu CP850 (durch hin- und Rueckrechnen der
Microsoft-Tabellen cp850.txt und bestfit1252.txt beim
Unicode-Material ftp.unicode.org)

#VSr ist eine errechnete RTF-Darstellung (zumindest unter
Win2000 und XP kann das *Anzeigefenster* ja Unicode-Zeichen
darstellen, wenn sie auf RTF-art codiert sind).

Der Satz bildet dann folgende Schluessel (11 ist in dieser
Anwendung das Ersetzungsschluesselregister):

|:latin small letter a with macron _&#x0101;

|;āa⌂
|;&#x0101;a⌂
|;āa⌂
|;Uā─ü
|;U&#x0101;─ü
|;Uā─ü
|;Wā\u257\'61
|;W&#x0101;\u257\'61
|;Wā\u257\'61

D.h. in der "Grundeinstellung" der Schluessel &...; ohne
Praefix sind der SGML-Name "amacr" und die beiden numerischen
Darstellungen, die abschliessenden Kloetzchen 127 schuetzen den
vorstehenden Inhalt, der koennte ja z.B. Spatium sein fuer
enspace etc.

Mit Praefix "U" wird ein Mapping zu UTF-8 geboten, mit Praefix
"W" zu RTF.

In die Indexparameter ist eine p-Tabelle geeignet fuer CP850
eingebunden, sowie eine o-Tabelle, die zwischen CP850 und CP1252
vermittelt, allerdings mit folgenden Abweichungen fuer Steuerzeichen:

p & 9
q & 9

damit die VS-Mechanik greift

p 170 1
q 170 1

fuer die Nichtsortierzeichen (wie immer)

p 127 1
fuer die Steuerkloetzchen

Im Kopf der Datei ist noch gesetzt

ib=59
  (";" soll das Endezeichen fuer die VS-Codes sein)

Der Primaerabschnitt enthaelt einigen Code fuer die Indexierung von
Saetzen mit #VS, eingeleitet mit
#bp & &
ausgeleitet mit
#bp & 9

Der zweite gebildete Schluessel in der .api (also der 1. im 2.
Indexlauf) ist wie oft ein unbedingter Sprung
ak=zz+0
und bei #-0 habe ich eingefuegt:

#dV

um die Sequenz-Ersetzungen global durchzufuehren (eine der beiden
Untervarianten dieser Unicode-Methode).

Damit Uebernahme von Codes anhand der verbalen Umschreibung
|:latin small letter a with macron _&#x0101;
im Register 10 moeglich ist, habe ich im PV-Abschnitt noch eingefuegt,
dass "Verknuepfungen" mit "_&..." um den Unterstrich zu erleichtern
sind.

In der DOS-Anzeigeparameterdatei d-1.cpr habe ich im Kopf ebenfalls
ib=59
eingefuegt und am Anfang der eigentlichen Befehle
#dV
(wer hier mit ak-Befehlen stark nach Satzarten differenziert, hat
evtl. mehr Arbeit).

Hinten bei der Umcodierung die bekannten
p & 9
p .127 1
p .170 1

Unter a99 war etwas mehr zu tun:

disphead.rtf enthaelt nur eine Deklaration fuer einen nicht allegro-
infizierten Textfont, Courier New (und disphead.rtf ist global fuer
alle Datenbanken in der zugehoerigen allegro-Installation, das wollte
ich nicht anfassen). Insofern muss die Parameterdatei mit

#t{"\f2\uc1 "}

beginnen (Font numero 2 ist "Courier New", "\uc1" sagt, dass hinter
\u-Befehlen mit Unicode-Nummern *1* Zeichen als Fallback folgt) und
darf nirgendwo auf andere Fonts umschalten.

Im Kopf der Datei nicht nur das bekannte
ib=59
sondern auch
ia=W
denn wir wollen die VS-Sequenzen hier ja nicht durch CP850-Annaeherungen
ersetzen sondern durch die mit Praefix "W" bereitgestellte RTF-
Codierung.

Merkwuerdigerweise musste ich auch
i6=11
deklarieren, das VS-Register muss zwar das fuer die normalen
v14-Ersetzungen sein, anders als PRESTO wird der Wert aber nur
fuer die v14-Ersetungen anhand der Indexparameter ermittelt...

Das Globale Ersetzen mit #dV funktioniert unter a99 ebenfalls nicht,
laesst man es weg funktioniert es mit der alternativen
Geschmacksrichtung aus VB164, d.h. die Sequenzen bleiben erhalten
und werden erst bei der eigentlichen Ausgabe umgewandelt. Das sollte
mir recht sein (mit PRESTO hingegen braucht man #dV, die andere
Variante funktioniert nicht...)

Anstatt d.apt ist wie beim Ersatz fuer die o-Tabelle die Konversion
CP850->CP1252 eingebunden.

Unschoenes Detail ist, dass es im (bewusst nicht genutzten) Bereich
von 128-159 von CP1252 kein Zeichen gibt, das sich zur Visualisierung
*und* Eingabe des Unterfelddreiecks eignet. Ich habe dann "$" gewaehlt,
mit der Konsequenz, dass literale "$" nun als "$" oder "$"
oder "&#x0024;" zu erfassen sind.

Ausserdem gab es im Index merkwuerdige Navigationsprobleme, wenn Zeilen
das Zeichen 127 (s.o.: "Schutz" von VS-Saetzen) enthielten, umbiegen
von 127 in der o-Tabelle scheint das Problem zu beheben.

An diesen Stellen weichen dann d.cpt und o.cpt vom Standard-Mapping
CP850<->CP1252 ab.

(ich war nicht so mutig, "$" global als Unterfeldzeichen in der .CFG
zu definieren, weil ich weiss, dass Ersetungsbefehle _..._..._ dann
schwierig werden)

d-rtf.cpt wurde nicht modifiziert (hier sind die p-Befehle fuer die
RTF-Escapes von "{", "}" und "\" enthalten, die sind weiterhin
wichtig. Hier wird auch eigentlich klar, dass man die #dV-Globalmethode
fuer RTF nicht *will*, denn sonst waeren unter keinen Umstaenden
umzuwandelnde "{" aus Sequenzersetzungen und unbedingt umzuwandelnde
"{" aus den eigentlichen Daten im Moment der Ausgabe nicht mehr
unterscheidbar...

Fuer die Internanzeige bei #-( habe ich etwas gearbeitet, damit die
VS-Sequenzen sichtbar werden:

Folgendes ist notwendig, weil F5 intern #bp 170 172 ausfuehrt, damit
wuerde das NSZ doppelt umcodiert werden, weil meine d-Tabelle mit
der "."-Variante der p-Umcodierungen arbeitet. Andere moegen das
Problem nicht haben...
#bp .170 .172   % magic override

Die VS-Eigenschaft von "&" muss aufgehoben werden
#bp & &

[
v14-Ersetzungen sollen anders dargestellt werden, funktioniert aber
nicht:
#bi4=5
]

Das (Umleitung auf ein nicht existierendes Praefix) ist komischerweise
auch noetig:
#bia=-       % VS-Ersetzungen umleiten

Dann kommt die pauschale Ausgabe (bei mir etwas umstaendlicher mit
#u01 geloest, damit ich nicht ze="\par" setzen muss, ausserdem werden
Kategorienummern eingefaerbt und aehnlicher Schnick),

Abschliessend dann das Rueckgaengigmachen der obigen Verbiegungen:
#bp & 9
#bi4=1
#bia=W

(#bp 170 170) macht a99 fuer einen.

Flips funktionieren nur eingeschraenkt, die 8-bit-Zeichensatz-Anwendung
erkennt die Inhalte nicht, es kommen nur Fragezeichen oder Schlimmeres.
Ich musste also auf die visuelle Variante mit einem pfeilartigen Zeichen
(">>") und daneben mikroskopisch und unsichtbar einem Zaehler
ausweichen:

#(L     #ucc als Flip, Springe in Register #uLI
#uLC x"+1" e"." =LC       % Zaehler erhoehen
#uLC p{"{\xfs2\'a0}{\cf2\ul\'bb{\fs2\cf0 "} P{"}\'bb}{\xfs2\'a0}"}
#uLC p"»" P"»" =Y~
#ucc

#uLI dcd f"?" p'x var "' Acd
#ucc u P'"' Acd
#uLI +#J00 i4,? p'\index|' e"|" Acd
#uLI +#J00 I4,? p'\Find|' e"|" Acd
#J00
#ucd =Z~
#)L

Das Flip-Kommando in #uZ... enthaelt dann die nicht aufgeloesten
VS-Sequenzen als Suchbegriff, das ist in Ordnung (die .cPI "weiss"
ueber die von ihr benoetigte Umcodierung besser Bescheid als
d-wrtf.cpr), in der .cpi habe ich die Umcodierungsabschnitte dann
generell so gestaltet:

#-4
#u1 u y3 =YY
!uYY
#+#

("y3" erzwingt eine reine VS-Ersetung, anschliessend wird innerhalb
CP850 auf Kleinbuchstaben etc. codiert. Mit #dV haette es vielleicht
auch funktioniert)

Cut & Paste war dann die Herausforderung. Auch das Schreibfeld von a99
ist eine 8-bit-Font-Angelegenheit, versucht man aus der
Windows-Zeichentabelle oder aus dem Anzeigefeld hineinzukopieren, kommen
bei den komplexeren Zeichen nur Fragezeichen an. Ich habe daher einen
Flex tojan.flx gebaut, der (auf Alt-9 gelegt) den Inhalt des
Schreibfelds an Janas schickt (o.k., jetzt testen wir bereits v24.0):

- ----%<--Schnipp
tojan.flx: Schreibfeld in HTML-Textarea zur Bearbeitung anbieten

var "tojan.htm"
open x
wri '<html><head><meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"></head>' n
wri '<body><form name="schreibfeld" action="flex:X fromjan.flx"
accept-charset="utf-8" method="post">' n
wri '<textarea name="ujn" rows="10" cols="72">'
var w
ins _<_<_
write
wri '</textarea>' n
wri '<input type="submit" />' n
wri '</body></html>' n
close x

var W
ins _\\_/_
ins #ucc
var "file:///" #ucc "/tojan.htm"
janas

Die Daten im Schreibfeld sind per Definitionem ISO-8859-1, "&" ist
ebenfalls per Definitionem bereits durch "&" escaped, die einzig
noch noetige Umwandlung ist daher die Zeile
ins _<_<_
gewesen.

Das funktioniert auch sehr schoen, der Inhalt des Schreibfelds erscheint
in Janas (die &-Sequenzen werden als die repraesentierten Zeichen
gezeigt, aber das war ja Sinn der Angelegenheit: Aus fremden Texten oder
aus der Windows-Zeichentabelle kann man nun mit Cut&Paste ergaenzen),
auch Zeilenbrueche aus dem Schreibfeld bleiben erhalten. (Strg-C und
Strg-V funktionieren in Janas nicht, damit laesst sich evtl. leben).

Der Rueckweg von Janas in das Anzeigefeld laeuft so:
Janas als Browser liefert UTF-8 zurueck, weil ich eine Ucodes.cpt
hinterlegt habe, die *nur* die Umwandlung des Umfangs von ISO8859-1
nach CP850 definiert, koennen alle anderen UTF-8-Codes von a99 wieder in
numerische Entitaeten &#nnn; zurueckgewandelt werden.
Das HTML-Formular ist so gestaltet, dass die Inhalte in die Variable
#ujn gesetzt werden, dann wird fromjan.flx (s.u.) aufgerufen, der
a99-seitig die Umwandlung vornehmen soll)

Janas funktioniert allerdings so, dass ein j.flx davorgeschaltet wird:

set U2
set c1
#ujn (Es folgt der Inhalt des textarea)
set U0
set c0
act
exec X fromjan.flx

U2 wuerde UTF-8-Codes, die von den u-Umwandlungen in ucodes.cpt nicht
abgedeckt werden, so lassen, wie sie sind, wirkt aber sowieso nicht,
weil #ujn eine Anwendervariable ist (und set U wirkt nur auf
Kategorien). Insofern kann fromjan.flx ungestoert die von mir benoetigte
Umwandlung mit set U1 ausfuehren.

Allerdings:
1. Gegen "&" fuer literale "&" in den Daten kann man sich nicht
wehren, das wird von janas so geliefert, in j.flx entsteht dort ein
Zeilenumbruch mit Schrott:

Aus "#21 Sieler & Vogel <Leipzig> {k}

wird in j.flx

#ujn #21 Sieler
# Vogel <Leipzig> {k}

2. Nur wenn ein Zeichen jenseits von ISO-8859-1 in den Daten vorkommt,
schickt der Browser UTF-8, sonst schickt er 8-Bit-Zeichen und die
Umcodierung mit ucodes.cpt scheitert grandios (keine Ahnung, ob das
ein IE- oder ein Janas-Problem ist, moeglicherweise laesst es sich
loesen, indem man nicht ISO-8859-1 schickt, sondern UTF-8).

3. bei mehrzeiligen Inhalten in #ujn (da textarea im Browser) landet die
erste Zeile in #ujn, die weiteren werden als Code in j.flx injiziert,
sind also guenstigstenfalls fuer weitere Verarbeitung verloren,
unguenstigstenfalls schmiert a99 ab oder ein geschickter Befehl loescht
die ganze Datenbank Satz fuer Satz.

4. set U funktioniert nur fuer Kategorien, nicht fuer u-Variable, man
muss dann etwas rudern, um #ujn nach #u1 zu bringen, umzuwandeln und
wieder abzuholen und #u1 wieder zu loeschen (und das "xxx" muss auch
sein, sonst wird das Spatium gefressen, wenn #ujn mit einer
Kategorienummer beginnt):

fromjan.flx (#ujn mit U1 verarbeiten und ins Schreibfeld)

set U1
var "#u1 xxx" #ujn
ins
set U0
var #u1(b"xxx")
ins _<_<_      (noetig?)
ansi
show iv
var ""
ins #u1

5. Unschoen ist auch, dass wegen der Operation mit #u1 der Satz
anschliessend als geaendert gilt (dabei sollte ja nur der Janas-Inhalt
ins Schreibfeld ueberfuehrt und eben noch nicht im Datensatz versenkt
werden).

Also: Die Kommunikation mit Janas war schon immer mein Haupteinwand
gegen eine sinnvolle Nutzung: Wieder werden irgendwo Dateien mit
festem Namen geschrieben, gelesen, zurueckgeschrieben und mit
Windows-weiten-Signalen geballert (dabei sitzt janas im gleichen
Prozess wie a99, was man schoen daran erkennen kann, dass man janas-
Fenster "ausradieren" kann, wenn a99 auf eine Eingabe wartet).
Nun ist aber zusaetzlich klar, dass der Weiterverarbeitungsmechanismus
a99-seitig so nicht brauchbar ist. Rettung sehe ich eigentlich nur
darin, dass die erhaltenen Daten 1:1 in die iV gesetzt werden und
der spezifizierte Flex direkten Zugriff darauf hat. Der Aufbau der
anzuzeigenden HTML-Seite sollte ebenfalls ohne Zwischendatei
erfolgen...

viele Gruesse
Thomas Berger

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

iD8DBQFGebBIhKFJT0F1FsoRAugxAJ9Wy41I+WZ2D9it1TnqC7KEsh+l5QCfcK1D
AQtyZYGRDUY2VBY36ohhPOw=
=2r9G
-----END PGP SIGNATURE-----