[Top][All Lists]

[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

From: Thomas Dickey
Subject: Re: Errors in terminfo.src for vt52, h19 and xterm-vt52 alternate character set info
Date: 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
image on 
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]