Doctor Who wrote to All <=-
Would it be possible (or is it already possible) to have
Synchronet detect the capabilities of a terminal and choose to use
80x24 cp437/ANSI files for those terminals and use larger sizes like 160x48 (or other arbitrary sizes) and UTF8 encoded files for users with larger terminals?
I've written one of the terminals that can do multiple codepages and
emulations (qodem). This will get more technical, but perhaps it will
be useful.
Detecting screen size is usually already done by modern BBS systems,
typically by setting the cursor to a "large" row/column and issuing
DSR 6 to have the terminal report its cursor position. However, there
is another way to figure out the screen size without actually using a ANSI/VT100 sequence, using features of the underlying connection
protocol. Telnet has the Negotiate About Window Size option, ssh has
the window-change message, and rlogin has a screen/window size
exchange that requires the BBS side to send TCP out-of-band data
(which has a strong chance to fail due to differences in how Windows,
BSD, and Linux handle their sockets layer, see RFC 6093). Both
options (DSR and the protocol specific stuff) work rather well, and
can even handle resizing the screen on-the-fly. So that part is
mostly done.
Detecting UTF-8 however is a bit harder. Unicode formally defines the character encoding to occur "above" the connection layer and "beneath"
the emulation layer, so one could for example have UTF-8 encoding with
DOS ANSI.SYS and it would work as you would hope it to. But the
emulation has no idea that it is speaking UTF-8 (with yet another
exception for X10 mouse reporting which by default can trash a UTF-8
stream). There are also no control sequences in VT100 to figure out
the encoding or codepage, but one could easily add a new constant to
the VT100 Device Attributes function to identify it (getting agreement
from all the terminal authors OTOH would be very hard, especially
given that some of the favorite BBS terminals are now abandonware and
cannot be updated). But one can look again at the connection protocol
layer, and telnet and ssh both provide means to pass environment
variables. (rlogin has nothing useful.) Hence the BBS could look at
the LANG variable to see if it is "en_US.UTF-8" instead of merely
"en_US", and switch to UTF-8 encoding appropriately (but this doesn't
help it pick an 8-bit codepage, e.g. CP437 vs KOI8-R for example).
Further ironically, even though telnet _can_ pass LANG, most telnetd
servers are hard-wired in the code not to: they will only pass a few
variables through and LANG is never one of them (nor are JOB, ACCT,
PRINTER, and SYSTEMTYPE, despite those being called out by name in RFC
1572 as well known variables). I am so used to telnetd not handling
LANG in fact that just verifying its behavior to write this post
showed me that my own telnet server code in my jexer library was
broken too! So I fixed that just now. :-) Happily enough though ssh
tends to be configured to pass LANG correctly.
So to recap, the screen size is working fine right now, but the UTF-8
detection would only work out-of-the-box for ssh. BBSes could check
LANG for telnet, but should probably also have a fallback because it
will often not work.
... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.49
þ Synchronet þ Vertrauen þ Home of Synchronet þ
telnet://vert.synchro.net