Hello All!

Habe einen GoldED+ gebaut, der Text intern als UTF-8 hält. Nach draußen
ändert sich dabei nichts - in die Echos schreibt er weiter das, was
XLATEXPORT sagt, also CP437 oder CP850 wie bisher.

Was das bringt:
- Nachrichten in verschiedenen Zeichensätzen stehen in einem Echo
nebeneinander und werden jede in ihrem eigenen angezeigt - CP437,
CP850, CP852, CP866, KOI8-R, ISO-8859, UTF-8
- unter Linux, BSD und macOS braucht es weder luit noch eine eigene
screen-Sitzung in einem alten Zeichensatz - er läuft im normalen
UTF-8-Terminal, so wie es ist
- im Windows Terminal und in der conhost belegt ein breites Zeichen
(CJK) seine zwei Zellen, statt in eine gequetscht zu werden und den
Rest der Zeile zu verschieben
- den Zeichensatz holt er sich vom System, einzustellen ist nichts
- umkodiert wird über iconv, unter Windows über die Codepage-API des
Systems, unter OS/2 über ULS. Die .chs-Tabellen braucht keiner mehr,
diese drei kennen alle Paare von sich aus. Unter DOS ebenfalls - im
Archiv liegt ein Build mit GNU libiconv, statisch gelinkt

Zum ersten Punkt ein eigener Absatz, denn darum geht es eigentlich.
Früher lag der Text intern einbyteweise, und damit hing alles am
Zeichensatz des Terminals. Eine Nachricht mit CHRS: CP866 hatte auf
einem CP437-Schirm schlicht keinen Platz - kyrillische Buchstaben gibt
es in CP437 nicht. Umgekehrt genauso: Umlaute und Akzente fehlen in
CP866 vollständig. Heraus kamen Fragezeichen oder Müll, und wer in
gemischten Echos las, sah die halbe Nachricht zerlegt. Jetzt ist der
Schirm UTF-8, und darin ist für alles Platz: eine deutsche Nachricht
in CP850, eine russische in CP866 und eine polnische in CP852 liegen
im selben Echo nebeneinander und werden alle drei so angezeigt, wie
sie geschrieben wurden.

Nebenbei ist CHRS: IBMPC sauber aufgelöst. Der Bezeichner ist alt und
unscharf: erst meinte er CP437, später "die Codepage der Maschine, auf
der die Nachricht geschrieben wurde". Bisher ging das aus Versehen gut
- eine IBMPC-Tabelle richtete niemand ein, die Bytes liefen unverändert
durch, und unter einem passenden Terminal kam das Richtige heraus.
Nimmt man IBMPC dagegen wörtlich als CP437, zerfällt eine russische
Nachricht. Aufgelöst wird er jetzt ausdrücklich: auf den Zeichensatz
der Sitzung, solange der einbyteweise ist, und in einer UTF-8-Sitzung
auf die DOS-Codepage, die das Locale nahelegt. Steht daneben ein
^ACODEPAGE:, hat das Vorrang, so wie FTS-5003 es verlangt.

CHRS: ASCII wird strikt als siebenbittiges ISO 646-1 genommen, wie im
Standard. Behauptet eine Nachricht ASCII und führt trotzdem Bytes über
0x7F mit sich, werden daraus Fragezeichen - aber die ist vom Absender
falsch ausgezeichnet, und die alten asc_*-Tabellen taten genau dasselbe.

Der Nodelist muss neu kompiliert werden. Im Index lag der Name in 36
Bytes, und das waren 36 Zeichen, solange ein Zeichen ein Byte war. In
UTF-8 kostet jeder Umlaut ein Byte extra - für deutsche Namen reicht
das meist immer noch. Kyrillisch, Griechisch und dergleichen kosten
dagegen zwei Bytes je Buchstabe, und da ist bei siebzehn Zeichen
Schluss: ein russischer Name mit 21 Zeichen braucht 41 Bytes und wurde mittendrin abgeschnitten. Das Feld fasst jetzt 80. Damit ändert sich
das Satzformat, ein altes .gxn nimmt GoldED+ nicht mehr an - lasst das
goldnode aus demselben Archiv darüberlaufen.

An Konfigurationsschlüsseln sind zwei dazugekommen:

XLATCONFIGSET - in welchem Zeichensatz GoldEDs eigene Dateien
geschrieben sind: golded.cfg, die Sprachdatei, die
Templates, die Tagline-Dateien, die Hilfe
XLATAREASET - in welchem Zeichensatz die Echo-Beschreibungen in
der Area-Datei des Tossers stehen. Fehlt er, gilt
XLATCONFIGSET

Beide Zeilen gehören ganz an den Anfang der Konfiguration, vor jede
Zeile mit einem nicht-englischen Wert: die Werte werden umkodiert,
während die Datei gelesen wird. Der typische Fall ist ein Terminal,
das längst UTF-8 spricht, während Konfiguration und Sprachdatei in
CP850 geblieben sind:

XLATCONFIGSET CP850

Dazu gibt es die Umgebungsvariable GOLDED_CONSOLE (nur Windows): cells
oder stream, falls GoldED nicht richtig errät, wie Deine Konsole
breite Zeichen zeichnet.

Und wer tatsächlich in UTF-8 schreiben will - dafür gibt es die Echos
UTF-8 und UTF8.FTN.MESSAGING. Beim Uplink bestellen und dort in jeder beliebigen Sprache schreiben. Ich habe dafür eine eigene Gruppe:

GROUP UTF-8;
MEMBER UTF-8, UTF8.FTN.MESSAGING
XLATIMPORT UTF-8
XLATEXPORT UTF-8
ENDGROUP

In allen anderen Echos bleibt dabei alles so, wie es war.

Gebaut sind fünfzehn Varianten - DOS, OS/2, Windows (MSVC6
eingeschlossen), Linux, macOS, Solaris, Haiku:

https://github.com/evs38/golded-plus/releases

Wer selbst baut:

git clone https://github.com/evs38/golded-plus.git

Der Zweig unicode ist dort der voreingestellte. Gebaut wird wie
gewohnt, mit cmake oder make PLATFORM=lnx; Einzelheiten stehen in
INSTALL und docs/building.txt.

Woraus gebaut wird: auf den Unixen braucht es curses und iconv.

Zu curses ein eigenes Wort, denn gerade ist Übergangszeit und man
vergreift sich leicht. Die Arbeit mit breiten Zeichen steckte in einer
eigenen Bibliothek namens ncursesw, und in vielen Systemen gibt es die
so nicht mehr - seit ncurses 6 liegen alle breiten Funktionen direkt
in der normalen ncurses, und ncursesw ist entweder nur noch ein
Verweis darauf oder ganz verschwunden. In pkgsrc etwa gibt es keine
eigene ncursesw mehr, nur noch ncurses - und die kann es bereits. Auf
älteren Systemen sind es dagegen weiterhin zwei verschiedene Pakete,
und gebraucht wird das mit dem "w".

Die Regel ist einfach: gibt es im System ein ncursesw, nimm das. Gibt
es keines, stecken die breiten Funktionen schon in der normalen
ncurses, dann nimm die. Der Build sagt anschließend selbst, was er
gefunden hat und ob es breite Zeichen kann.

iconv steckt unter Linux in der libc selbst, unter BSD und macOS
installiert man üblicherweise libiconv aus den Paketen dazu.

Unter Windows braucht es weder das eine noch das andere: den Schirm
zeichnet die Konsole selbst, umkodiert wird über die Codepage-API des
Systems. Unter OS/2 dasselbe - VIO für den Schirm, ULS fürs Umkodieren.
Unter DOS wird libiconv für djgpp gebraucht, sofern mit ICONV=1 gebaut
wird.

An Build-Schaltern sind dazugekommen (im make so, in cmake dasselbe
über -D, bei den letzten beiden mit dem Präfix GOLD_):

GOLD_UTF8=0 Text weiter einbyteweise halten, wie bisher.
Voreingestellt ist 1, außer unter DOS
WIDE_NCURSES=0 mit dem alten, achtbittigen curses arbeiten, auch
wenn eine Bibliothek mit Unterstützung für breite
Zeichen gefunden wurde
EXTERNAL_CURSES=0 curses nur aus dem System nehmen, nicht aus den
Paketen
EXTERNAL_ICONV=0 dasselbe für iconv

Voreingestellt werden curses und iconv auf den Unixen aus dem
Paketmanager genommen (/usr/pkg, /usr/local, /opt/homebrew, /opt/local, /opt/csw), das System ist der Rückfall: das ncurses aus den Paketen ist
meist neuer und kann breite Zeichen, und das libiconv aus den Paketen
kennt mehr Zeichensätze.

Unter OS/2 läuft das Umkodieren über ULS, die Unicode-Unterstützung des Systems. Sie wird von selbst genommen, sobald die Header des OS/2
Toolkit gefunden werden; fehlen sie, wird auf Tabellen gebaut.

Der DOS-Build im Archiv ist mit ICONV=1 gebaut, libiconv für djgpp ist
statisch einkompiliert, .chs-Tabellen braucht es dort also nicht. Ohne
ICONV=1 bleibt DOS auf den Tabellen, wie gehabt.

Fehler dürften reichlich drin sein: GoldED ist ein riesiger Baukasten,
über Jahre gewachsen, und alle seine Funktionen kennt längst niemand
mehr :) Angefasst wurde dabei fast alles, wo Text auf den Schirm kommt.
Wer also etwas findet - schreib, ich sehe es mir an.

* Originally in FIDOSOFT.GER
* Crossposted in GOLDED.GER

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)