AW: [Allegro] Update mit update.flx

[Thomas Fischer]

Hallo Herr Eversberg,

ich bin aus dem Urlaub zurück und habe mir die Testdatenbank
heruntergeladen, um das Verhalten zu testen:

> > 2.
> > Zu der Frage der Wirkung von y2: Gibt es eine funktionierende
> > Testdatenbank mit UTF-8, an der ich das testen könnte?
> >
> Hier liegt sie:
>  <http://ftp.allegro-c.de/aktuelle-version/demou.lzh>
http://ftp.allegro-c.de/aktuelle-version/demou.lzh

Ausnahmsweise sende ich den Brief HTML-formatiert in der Hoffnung, dass die
Diakritika so erhalten beleiben. Ich bitte die Redundanz mit der Erwähnung
des "Hatschek" zu entschuldigen, aber sonst  geht das Argument verloren,
falls irgend etwas entlang der Mailkette wie bei meiner früheren Mail das
Zeichen entfernt.

Aufgefallen ist mir bisher:

1. Beim Start der Datenbank wir im Anzeigefeld etwas unleserliches
produziert:
Verfasser:      ????, ?????? ??????
Titel:          ??????????????? ??????????. ?????????? ???????? : ???????
??????????. ???. ? ????? ???????. ...
Umfang:         254,[2] ?
Serie:          ???????? ??????
ISBN:   5-87604-005-3
Anm.:   ????????. ? ??????.: ?. 214-244; ????.: ?. 245-254

Nach F5 wird die Anzeige korrekt. Warum das so ist, weiß ich nicht.

2. Die Überschriften der Register (in CAT.API) sind noch in DOS-ASCII,
müssen für die Anzeige aber in ANSI sein.

3. Ich habe versucht, mein Beispiel
Cech, Eduard
in UTF-8 (C mit Hatschek) in einem Datensatz einzugeben. Dann wird das
Hatschek nicht angezeigt.
Um Unterschiede zumindest sehen zu können, habe ich in D-KRTF.APR den Befehl
tutf-rtf
deaktiviert und disphead.rtf auf urtf1 umgestellt.
Damit wird Cech (C mit Hatschek) korrekt dargestellt.
 
Nebenbei bemerkt leistet utf-rtf.apt keinesfalls was der Name verspricht:
Statt die UTF-8 Kombinationen geeignet umzusetzen, z.B. für mein C:
P 196 140 "\u268?"
steht dort
P 196 140 C   [010C] -- &#268
das Hatschek wird also einfach ignoriert, nur die Unicode-Zeichen zwischen
1040 und 1103 werden umgesetzt.
Das lässt sich leicht korrigieren (wenn man eine Texteditor mir regulären
Ausdrücken benutzt), irritiert aber unnötig.
Ich vermute, dass dies daran liegt, dass für die Demo-Datenbank kein eigenes
dishead.rtf gesetzt und so für die Anzeige allegro New Roman benutzt wird,
was für die Präsentation von Unicode ziemlich ungeeignet ist.

4. Mit der gegebenen cat.api bekommt man für den Index die folgenden
Einträge aus #u1:
y0 Cech, Eduard
y1 CECH, EDUARD
y2 cech, eduard
alle ohne Hatschek.
Das von mir beschriebene Problem kann also gar nicht auftreten, weil das
Hatschek schon zwischen dem Eintrag und #u1 "gekillt" wird.
Das geschieht wohl durch iu.apt (swl1.apt kann es nicht sein, und o.apt ist
praktisch leer).
 
Herr Eversberg, können Sie mir noch einmal erklären, wie man (mit #u1?) an
den unveränderten Eintrag kommt? Oder wirkt hier für die Anzeige mit F7 noch
ein zusätzlicher Mechanismus, der das  C (mit Hatschek) unterdrückt? 

Mit freundlichen Grüßen
Thomas Fischer 

 





-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20090914/418fb7ef/attachment.html>