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

[Ben Wiley Sittler]

I have since rethought that -- a better name would be 'ucsc' and it
should definitely be a separate capability. For portability I think it
makes sense for the terminfo capabilities themselves to remain 8bit,
and so the calling program (typically ncurses) would need to parse the
\uXXXX escapes. And actually there's no reason a ucsc translation
can't describe the same 8-bit character described by an acsc
translation. In fact that could help with the long-standing major
differences in e.g. ACS_BULLET across terminals -- on some it is a
small middle dot, on others a large block, and on still others a large
round bullet, and software using it has had to guess, or just use it
and hope it's appropriate in whatever context it's being used.

On 10/22/07, Ben Wiley Sittler <address@hidden> wrote:
> Ah, sorry I misread the terminfo for vt52 and relatives! Any chance
> the h19/z100 acsc will make it into a future release?
>
> As for Unicode acsc correspondence, why not just define an escape for
> unicode characters? For those in the Basic Multilingual Plane (i.e.
> any likely to be encountered in an old terminal) the most widely-used
> notation is the Java one: \uXXXX, where each X is either upper- or
> lower-case hex and there are always exactly four of them per Unicode
> sequence. I'll go ahead and propose the following for extending acsc:
>
> acsc=\uXXXXY
>
> Would mean "send Y to achieve \uXXXX". Obviously this can be mixed
> with the regular acsc format, unless you're worried about apps that
> parse acsc themselves, in which case a separate capability name is
> needed (maybe acsu?)
>
> Obviously those characters already having notations in the ncurses
> acsc shouldn't be written this way. Uf this is too
>
> On 10/22/07, Thomas Dickey <address@hidden> wrote:
> > 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
> >
>