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)