[Allegro] Vorabdruck Vb.271 : Mehr zum Thema "Unicode intern"

[Fischer, Thomas]

Lieber Herr Eversberg,

Unicode Unterstützung jedweder Art begrüße ich sehr!

Ich meine mich aber zu erinnern, dass eine ziemlich leere o-Datei unschöne Effekte liefert bei der Anzeige von Hilfs- und ähnlichen Texten. Ist das behoben?

Mir ist auch unklar, wieso über aw-utf.apt der OSTWEST-Zeichensatz in die schöne Unicode-Umgebung hineingeschleppt wird, den möchte ich da lieber nicht haben.

Und warum schlagen Sie vor, utf-rtf.apt (besser eigentlich utf-rtf. at pt) zu benutzen? Mein Kollege Jiří aus Prag kann dann zwar so in der Datenbank stehen, in der Anzeige wird dann aber wohl ein JirÍ daraus, das muss doch nicht sein (das Í ist wohl ein Fehler in utf-rtf.apt, entweder in der Übersetzung oder der Beschreibung)!

Da ich wie schon mal erwähnt so etwas ähnliches auch seit einiger Zeit benutze, gleich noch die Zusatzfrage: Ich benutze verschiedene Tabellen, die der Tastaturauswahl des PC entsprechen, so dass man z.B. auf die ungarische Tastaturbelegung umschalten kann, um die entsprechenden Sonderzeichen einzugeben, ist das auch bei Ihnen vorgesehen?

Ich benutze ein etwas sperriges zur EXE kompiliertes Perlskript zur Umrechnung, das ich gerne durch ein echtes C(#)-Programm ersetzt sähe, wäre so etwas auch in Reichweite?

Mit freundlichen Grüßen
Thomas Fischer


> Am 24.07.2015 um 10:13 schrieb Bernhard Eversberg <b.eversberg at tu-braunschweig.de>:
> 
> 
> VORABDRUCK
> 
> Verlautbarung 271 der Entw.Abt.                              2015-07-28
> ———————————————

> Zum Thema "Unicode intern"
> --------------------------
> 
> Es soll mit V35.8 eine neue DemoBank geben, die intern in UTF-8 codiert
> ist, was auch bisher schon ging, nun aber mit etwas mehr Unterstuetzung
> in einigen wichtigen Funktionen.
> Was weiterhin und auch in Zukunft NICHT gehen wird, ist die Anzeige von
> UTF-Daten im Auswahlfeld, Schreibfeld, Befehlszeile und in den
> Formularen, vom Index gar nicht erst zu reden. Die dafür notwendigen
> Umstellungen der Kernprogramme sind nicht zu leisten, wie wir schon
> früher definitiv festgestellt hatten, um unrealistische Hoffnungen
> gar nicht aufkommen zu lassen.
> Im Anzeigefeld kann dagegen UTF-Text korrekt erscheinen, weil dies
> ein RTF-Feld ist, und ein solches ermöglicht die Anzeige, wenn die Daten
> in bestimmter Weise codiert sind, siehe unten 6. Das war auch schon
> bekannt, nun kommt eine verbesserte Bearbeitungsoption hinzu.
> 
> NEU...NEU...NEU
> ===============
> a99 : Bearbeitung von UTF-8-Daten im Anzeigefeld
> ------------------------------------------------
> [Nur fuer Datenbanken mit UTF-8 als interner Codierung!]
> Ein neuer FLEX namens  allers.flx  ermoeglicht es, im Anzeigefeld
> Datensaetze zu bearbeiten, die intern im UTF-8-Code vorliegen. Das ist
> der Fall bei der Unicode-Variante der DemoBank. Diese wird in
> aktualisierter Form neu bereitgestellt.
> Der FLEX heisst so, weil ein wesentliches UP vom Kollegen Heinrich
> Allers geschrieben wurde, der am 14.8.2013 tragisch ums Leben kam.
> Wir wollen damit seine Verdienste um allegro noch einmal wuerdigen.
> 
> Wie ist vorzugehen?
> 
> 1. Datensatz mit F5 in Kategorieform anzeigen lassen,
> 2. im Anzeigefeld bearbeiten,
> 3. mit  X allers  wieder einlesen in den Arbeitsspeicher,
>     Satz wird mit den Korrekturen erneut angezeigt.
> 4. Falls noch nicht ok, Vorgang ab 1. wiederholen
> 5. Falls ok, speichern.
> 
> Voraussetzungen in den Parametern etc.:
> 
> 1. o.apt: Nur die folgenden zwei Zeilen drin, sonst nichts:
>   o .31 178   Unterfeld-Dreieck
>   o .178 31   und umgekehrt
> 
> 2. INI-Datei: diese Zeile
>   Phrase=unicode.a99
> 
> 3. Datei unicode.a99 kann zunaechst eine Kopie sein von phrase.a99
>   Dann, falls Code 20 gewuenscht wie in Standardversion,
>   in  unicode.a99  diese 2 Zeilen:
>   20 = ^t
>   ¶
>   Dann ist mit Strg+t Eingabe des Absatzendezeichens ¶ moeglich
> 
> 4. d-krtf.apr  aus dem demou-Ordner als Anzeigeparameter nehmen,
>   Oder in den Anzeigeparametern muss der Abschnitt stehen,
>        der in d-krtf.apr unter #-( steht (Intern-Anzeige).
> 
> 5. aw-utf.apt  muss vorhanden sein (unveraendert seit 2005)
> 
> 6. Entweder
>   a) in den Anzeigeparametern den Befehl
>      tutf-rtf   zum Laden der Tabelle utf-rtf.apt
>   oder
>   b) die Datei disphead.rtf mit \urtf1 versehen in das DbDir
>      kopieren
> 
> Fuer Interessierte:
> allers.flx speichert die Anzeige als RTF-Datei mit "file record.rtf".
> Darin kann man sehen, dass die Unicode-Zeichen nicht als UTF-8
> gespeichert werden, sondern in der RTF-Codierung, also z.B.
> \u1057?  fuer das kyrillische C statt der 2 Bytes  D0 A1
> (egal wie man bei Punkt 6. vorgeht). Der allers.flx muss deshalb
> die Zahl 1057 wieder umrechnen in D0 A1. (Genau das hatte Allers
> seinerzeit programmiert.) Jedoch: Die im RTF-zeichensatz vorhandenen
> Zeichen werden beim Speichern nicht so codiert, sondern in der Notation
> \'hh mit zwei Hex-Ziffern, z.B. \'80 fuer den Euro und \'e4 für das ä.
> Dies war zusaetzlich zu programmieren, d.h. daraus beim Einlesen wieder
> die UTF-Codes C3 A4 fuer das ä zu machen. Der allers.flx ist sehr
> ausfuehrlich kommentiert. Wir haben damit erreicht, dass man fuer
> diesen Zweck keine Drittmittel wie etwa Perl einzusetzen braucht, denn
> so etwas wollen wir grundsaetzlich nicht dem Endanwender zumuten.
> 
> ***********************************************************************

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 842 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20150724/b1d890f0/attachment.sig>