bug-ncurses
[Top][All Lists]
Advanced

[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: Ben Wiley Sittler
Subject: Re: Errors in terminfo.src for vt52, h19 and xterm-vt52 alternate character set info
Date: Mon, 22 Oct 2007 18:11:28 -0700

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
>




reply via email to

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