@MSGID: 2:5075/35@fidonet 6a91d36a
@CHRS: CP866 2
@TZUTC: 0300
@TID: hpt/nbsd 1.9 2024-03-02
Hello All!

Собрал GoldED+, который держит текст внутри себя в UTF-8. В сеть при
этом ничего нового не уходит - в эхи пишет в CP866, как и писал.

Что это даёт:
- письма в разных кодировках в одной эхе показываются каждое в своей,
  одновременно - CP866, KOI8-R, CP1251, CP437, CP850, ISO-8859, UTF-8
- на linux/bsd/macos больше не нужен ни luit, ни отдельный screen в
  koi8-r - работает в родном UTF-8 терминале как есть
- в Windows Terminal и в conhost широкие символы (CJK) занимают свои
  две клетки, а не давятся в одну, разъезжая всю строку
- кодировку берёт из системы, настраивать ничего не надо
- перекодирует через iconv; на windows - системным интерфейсом кодовых
  страниц, на os/2 - через ULS. Таблицы .chs больше не нужны, эти знают
  все пары сами. И под DOS тоже - в архиве сборка с GNU libiconv

Про первый пункт подробнее, потому что он и есть главный. Раньше текст
внутри голдеда был однобайтовым, и всё упиралось в кодировку терминала.
Письмо с CHRS: CP437 или CP850 на экране в CP866 перекодировать было
некуда: ни умляутов, ни диакритики в CP866 просто нет. На их месте
получались вопросительные знаки или мусор - и немецкие, польские,
французские эхи читались как придётся. То же самое было с KOI8-R
терминалом. Теперь экран в UTF-8, а там есть всё сразу: немецкое
письмо в CP850, русское в CP866 и польское в CP852 лежат в одной эхе
рядом и все три показываются так, как написаны.

Заодно разобран CHRS: IBMPC. Идентификатор старый и мутный: сначала он
значил CP437, а потом стал значить "кодовая страница той машины, где
письмо писали" - то есть у нас CP866. Раньше это работало по
случайности - таблицы для IBMPC никто не заводил, байты шли насквозь,
терминал был в CP866, и выходило верно. А стоило понять IBMPC
буквально, как CP437, и русское письмо разваливалось. Теперь оно
разбирается явно: берётся кодировка сессии, если она однобайтовая, а на
UTF-8 сессии - DOS-кодировка из локали, у нас CP866. Если рядом стоит
^ACHRS или CODEPAGE: - он главнее, как и требует FTS-5003.

CHRS: ASCII понимается строго семибитным, ISO 646-1, как в стандарте.
Если письмо объявлено как ASCII, а внутри восьмибитные байты, они
станут вопросиками - но такое письмо помечено неверно самим
отправителем, и старый голдед с таблицей asc_* делал ровно то же.

Нодлист надо перекомпилировать. В индексе имя лежало в 36 байтах - это
36 символов, пока символ был байтом. В UTF-8 столько же занимают
семнадцать русских букв, и "Александр Христофоров" (41 байт) туда уже
не влезает - обрезается посередине. Поле расширено до 80. Формат записи
от этого поменялся, старый .gxn голдед не примет - гоняйте goldnode из
этого же архива.

Новых ключей в конфиге всего два:

  XLATCONFIGSET - в какой кодировке написаны собственные файлы голдеда:
                  golded.cfg, языковой файл, шаблоны, файлы таглайнов,
                  хелп
  XLATAREASET   - в какой кодировке описания эх в area-файле тоссера.
                  Не задан - берётся XLATCONFIGSET

Обе строки должны стоять в самом начале конфига, до любой строки с
неанглийским значением: значения перекодируются по мере чтения файла.
Типичный случай - терминал уже UTF-8, а конфиг и языковой файл остались
в CP866:

  XLATCONFIGSET CP866

Ещё есть переменная окружения GOLDED_CONSOLE (только Windows): cells
или stream - если голдед не угадал, как ваша консоль умеет рисовать
широкие символы.

А если хочется именно писать в UTF-8 - для этого есть эхи UTF-8 и
UTF8.FTN.MESSAGING, подписывайтесь у аплинка и пишите там на любом
языке. У меня под них отдельная группа:

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

В остальных эхах при этом всё остаётся как было, в CP866.
Собранное - пятнадцать вариантов, DOS, OS/2, Windows (в том числе
MSVC6), Linux, macOS, Solaris, Haiku:

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

Кто собирает сам:

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

Ветка unicode там по умолчанию. Собирается как обычно - cmake или
make PLATFORM=lnx (или что там у вас), подробности в INSTALL
и docs/building.txt. На юниксах нужны curses и iconv.

Про curses стоит сказать отдельно: сейчас идёт переходный период и
легко промахнуться. Работа с широкими символами жила в отдельной
библиотеке ncursesw, и во многих системах её больше нет как таковой -
начиная с ncurses 6 все широкие функции лежат прямо в обычной ncurses,
а ncursesw либо осталась ссылкой на неё для совместимости, либо
исчезла совсем. В pkgsrc, например, отдельной ncursesw уже нет, там
только ncurses - и поддержка там уже есть. Но на системах постарше это
до сих пор два разных пакета, и нужная - та, что с "w".

Правило простое: есть в системе ncursesw - ставьте её. Нет - значит
широкие функции уже в обычной ncurses, ставьте её. Сборка потом сама
напишет, что нашла и умеет ли оно широкие символы.
iconv на linux сидит в самой libc, на bsd и macos обычно ставится
отдельной libiconv из пакетов, но бывают и случаи когда есть старый
curses прямо в системе (как в NetBSD).

На Windows не нужно ни того, ни другого: экран рисует сама консоль,
перекодировкой занимается системный интерфейс кодовых страниц. На OS/2
то же самое - VIO для экрана и ULS для перекодировки. Под DOS нужен
libiconv для djgpp, если собирать с ICONV=1.

Что появилось из ключей сборки (в make так, в cmake то же самое через
-D, с префиксом GOLD_ у последних двух):

  GOLD_UTF8=0        держать текст однобайтовым, как раньше. По
                     умолчанию 1 везде, кроме DOS
  WIDE_NCURSES=0     работать со старым, восьмибитным curses, даже
                     если найдена библиотека с поддержкой широких
                     символов
  EXTERNAL_CURSES=0  брать curses только системный, не из пакетов
  EXTERNAL_ICONV=0   то же про iconv

По умолчанию на юниксах curses и iconv берутся из пакетного менеджера
(/usr/pkg, /usr/local, /opt/homebrew, /opt/local, /opt/csw), системные -
запасной вариант: пакетный ncurses обычно новее и умеет широкие
символы, а пакетный libiconv знает больше кодировок.

На OS/2 перекодировка идёт через ULS - это системная работа с
Юникодом. Подхватывается сама, если найдены заголовки OS/2 Toolkit;
если их нет, сборка получится на таблицах.

DOS-сборка в архиве собрана с ICONV=1, libiconv для djgpp вкомпилирован
статически, так что таблицы .chs там не нужны. Если собирать без
ICONV=1, DOS останется на таблицах, как раньше.

Багов наверняка много: голдед - здоровенный конструктор, который рос
годами, и всех его функций толком никто уже не помнит :) Трогали при
этом почти всё, где на экран попадает текст. Так что найдёте глюки -
пишите, разберу.

--- English announce ---

Built a GoldED+ that holds text as UTF-8 internally. Nothing changes on
the wire - it writes to echoes in whatever XLATEXPORT says, as before.

What it buys you:
- messages in different charsets in one echo are each shown in their
  own, all at once - CP437, CP850, CP866, KOI8-R, ISO-8859, UTF-8
- on unix and macOS no more luit and no more separate screen session in
  a legacy charset - it runs in the native UTF-8 terminal as it is
- in Windows Terminal and conhost a fullwidth character (CJK) takes the
  two cells it is due instead of being squeezed into one and shifting
  the rest of the line
- charset comes from the system, nothing to configure
- conversion goes through iconv; on Windows through the codepage API,
  on OS/2 through ULS. No more collecting .chs tables for the pairs you
  need: these know them all. DOS included - the build in the archive
  carries GNU libiconv, statically linked

The first point deserves spelling out, because it is the whole reason
for the exercise. Text inside GoldED+ used to be single-byte, so
everything came down to the terminal`s charset. A message tagged
CHRS: CP437 or CP850 had nowhere to go on a CP866 screen - CP866 has no
umlauts and no accented Latin at all. You got question marks or garbage
instead, and German, Polish and French echoes read like a lottery. Same
story on a KOI8-R terminal. Now the screen is UTF-8, which has room for
all of it: a German message in CP850, a Russian one in CP866 and a
Polish one in CP852 sit side by side in one echo and all three come out
as written.

CHRS: IBMPC is sorted out too. It is an old, vague identifier: first it
meant CP437, then it came to mean "the codepage of the machine the
message was written on". It used to work by accident - nobody
configured an IBMPC table, the bytes went through untouched, and under
a matching terminal that was the right answer. Take IBMPC literally as
CP437 and a Russian message falls apart. It is now resolved properly:
the session charset when that is single-byte, and on a UTF-8 session
the DOS codepage the locale implies. A ^ACODEPAGE: line next to it wins
over IBMPC, as FTS-5003 requires.

CHRS: ASCII is taken strictly as seven-bit ISO 646-1, per the standard.
If a message claims ASCII and carries eight-bit bytes anyway, those
become question marks - but that message is mislabelled by its sender,
and the old asc_* tables did exactly the same thing.

Recompile your nodelist. The index held a name in 36 bytes, which was
36 characters while a character was a byte. In UTF-8 that is seventeen
Cyrillic letters, so a name like "Александр Христофоров" - 41 bytes -
no longer fits and got cut in the middle. The field is 80 now. That
changes the record format, GoldED+ will not touch an old .gxn - run
goldnode from the same archive.

Two new keywords, that is all:

  XLATCONFIGSET - the charset GoldED+`s own files are written in:
                  golded.cfg, the language file, templates, tagline
                  files, the help file
  XLATAREASET   - the charset of area descriptions in your tosser`s
                  area file. Unset, it follows XLATCONFIGSET

Both belong at the very top of the configuration, ahead of any line
whose value is not plain ASCII - values are converted as each line is
read. The usual case is a UTF-8 terminal with an older config and
language file:

  XLATCONFIGSET CP866

There is also a GOLDED_CONSOLE environment variable (Windows only):
cells or stream, for when GoldED+ guesses wrong about how your console
draws a fullwidth character.

And if you do want to write in UTF-8, there are echoes for exactly
that - UTF-8 and UTF8.FTN.MESSAGING. Ask your uplink for them and
write in any language you like. I keep a group for them:

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

Everything else stays 8-bit as it was.

Built - fifteen of them, DOS, OS/2, Windows (MSVC6 included), Linux,
macOS, Solaris, Haiku:

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

If you build your own:

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

unicode is the default branch there. Builds as usual - cmake, or
make PLATFORM=lnx; see INSTALL and docs/building.txt.
On unix, curses and iconv are required.

Curses deserves a word: this is a transition period and it is easy to
get wrong. Wide-character support used to live in a separate library,
ncursesw, and in many systems that library no longer exists as such -
since ncurses 6 the wide calls sit in the ordinary ncurses, and
ncursesw is either a compatibility symlink to it or gone entirely.
pkgsrc, for one, has no separate ncursesw any more, only ncurses - and
it is the wide one. On older systems, though, they are still two
different packages, and there the wide one is exactly the one with the
"w".

The rule is simple: if your system has ncursesw, install that. If it
does not, the wide calls are already in the plain ncurses - install
that. The build then tells you what it found and whether it is wide.
iconv is part of libc on Linux; on the BSDs and macOS it is usually a
separate libiconv from packages.

On Windows neither is needed: the screen goes through its own console
layer and conversion through the codepage API. On OS/2 it is VIO and
ULS, both system. On DOS you need libiconv for djgpp if you want to
build with ICONV=1.

New build switches (make form below; cmake takes the same through -D,
with a GOLD_ prefix on the last two):

  GOLD_UTF8=0        hold text single-byte, as before. Default is 1
                     everywhere except DOS
  WIDE_NCURSES=0     the old 8-bit curses API instead of the wide one
  EXTERNAL_CURSES=0  use only the system`s curses, not a packaged one
  EXTERNAL_ICONV=0   the same for iconv

By default on unix both come from the package manager (/usr/pkg,
/usr/local, /opt/homebrew, /opt/local, /opt/csw) with the system`s own
behind them: a packaged ncurses is usually newer and wide-capable, and
a packaged libiconv knows more charsets.

On OS/2 conversion goes through ULS, the system`s Unicode API. It is
picked up by itself when the toolkit headers are found; without them
you get a build on the tables. The DOS build in the archive is made
with ICONV=1 and libiconv for djgpp linked statically, so the .chs
tables are not needed there either; built without ICONV=1, DOS stays on
the tables as before.

There are bound to be plenty of bugs: GoldED+ is a huge construction
set grown over decades and nobody quite remembers all of its features
any more :) and almost everything that puts text on the screen was
touched here. So find bugs and write, I go through all of it.

Eugene

... It`s full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
 * Origin: FireFox Station (2:5075/35)
SEEN-BY: 5001/100 5015/46 255 5019/40 5020/715 848
1042 1146 4441 12000
SEEN-BY: 5030/1081 5051/44 5057/19 5075/35
6078/80
@PATH: 5075/35 5020/4441 715