[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Errors in terminfo.src for vt52, h19 and xterm-vt52 alternate charac
Re: Errors in terminfo.src for vt52, h19 and xterm-vt52 alternate character set info
Mon, 22 Oct 2007 20:39:34 -0400 (EDT)
On Mon, 22 Oct 2007, Ben Wiley Sittler wrote:
After a bit of investigation, it looks like terminfo.src is wrong
about the alternate character set on the h19/z100 terminal family and
on the vt52 (the real thing, as opposed to the vt100 running in vt52
The h19/z100 family actually have this acsc correspondence:
The rest is assorted half- and quarter-block characters, diagonal
line-drawing characters, left and right scanlines, etc. see e.g. the
for a description.
And here's the vt52 this acsc correspondence:
I've got this in vt52 at the moment:
For the other two (h19, z100), terminfo.src has no acsc defined,
which would make ncurses default to using the vt100 acsc.
The rest of the vt52 alternate character set is a bunch of fraction
parts, subscript digits, and other assorted symbols.
I'm sort of aware of that (had used a vt52 for a few years at the end of
the 70's, etc).
However a vt100 or xterm emulating a vt52 (that is, after rceiving
"\E[2l" ) still uses the vt100 alternate character set. so for
"xterm-vt52" this should be as for regular xterm:
But I do that - in xterm and ncurses both (unsure what you're
I resync the terminfo in xterm and ncurses periodically using an
infocmp-based script - don't recall having acsc mismatches.
Also, are there any plans to extend terminfo to support unicode acsc
information? That is, the rest of the h19/z100 and vt52 alternate
character sets could easily be described by correspondence to unicode
characters, and ncurses could map appropriately while displaying.
I hadn't considered that - since outside of the slight superset of vt100
that acsc normally defines, there's no real standardization. ncurses
uses Unicode values directly when the acsc cannot be used.
Just a thought... maybe there's a way to do this and i just don't know it?
Well the basic problem with extending acsc is that it's a well-defined
8-bit string. One could make an analogous wide-character string, but
there's a lot of inertia in the existing system (and none of the schemes
I've seen would be a real improvement). Several people have asked about
this, but no one's proposed a definite scheme for consideration.
Thomas E. Dickey