Re: Errors in terminfo.src for vt52, h19 and xterm-vt52 alternate character set info

[Thomas Dickey]

On Mon, 22 Oct 2007, Ben Wiley Sittler wrote:

> Hi,
>
> 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
> mode).
>
> The h19/z100 family actually have this acsc correspondence:
>
> acsc=~^x`qanbkcjdmelfgg+hai.kwsutvutvozs{
>
> The rest is assorted half- and quarter-block characters, diagonal
> line-drawing characters, left and right scanlines, etc. see e.g. the
> image on 
> http://home.comcast.net/~davidwallace2000/h8/project8080_archive/pgs/h19esc.html#modes
> for a description.
>
> And here's the vt52 this acsc correspondence:
>
> acsc=0affgg+h.kolpmqorrss

I've got this in vt52 at the moment:

  acsc=.kffgghhompoqqss

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:
>
> acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~

But I do that - in xterm and ncurses both (unsure what you're
comparing)

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
http://invisible-island.net
ftp://invisible-island.net