bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug in the alternate character set output


From: Thomas Dickey
Subject: Re: bug in the alternate character set output
Date: Sat, 10 Sep 2011 17:16:36 -0400
User-agent: Mutt/1.5.18 (2008-05-17)

On Fri, Sep 09, 2011 at 11:29:41AM +0400, Alexei Malinin wrote:
> Nicholas Marriott wrote:
> > I get the same results on Linux and OpenBSD so if this is a problem I
> > suspect it is ncurses rather than OpenBSD.
> >
> > You can take this to ncurses-dev or I will have a dig around when I have
> > time, it'd help if you can come up with a simpler example (perhaps where
> > you only change the x member of acsc).
> >
> >
> > On Mon, Jul 18, 2011 at 04:28:41PM +0400, address@hidden wrote:
> >   
> >> Synopsis:  bug in the alternate character set output
> >> Category:  system
> >> Environment:
> >>            System:         OpenBSD 4.2 & 4.9
> >>            Architecture:   OpenBSD.i386
> >>            Machine:        i386
> >> Description:
> >>            curses and the like applications display curses ACS_VLINE
> >>            characters incorrectly if the ACS_VLINE character is set
> >>            to "|"
> >> How-To-Repeat:
> >>            let's prepare test terminfo entry, where curses ACS_VLINE
> >>            character is set to "|" (i. e. acsc must have "x|"
> >>            somewhere in a terminfo description):

But your example isn't doing that.  It's assigning it to the alternate
character set's entry in the "|" position.  What's actually displayed
depends on the terminal implementation (and fonts).

Some implementations for instance will show blanks if there's a mapping
to an unexpected character, some will show the original character which
is mapped, and - there are probably other interesting cases.

To get a sense for what to expect, look at vttest or the ncurses test-program.

> >> # cd               
> >> # vi xterm0.ti
> >> # cat xterm0.ti
> >>
> >> # ACS test
> >> xterm0|xterm with simple ASCII pseudographics,
> >>    acsc=+>\,<-\^.v0#`+a\:f\\h#j+k+l+m+n+o~p-q-r-s_t+u+v+w+|!}#~ox|,
> >>    use=xterm,

Here's what xterm has related to alternate character set:

        acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        rmacs=\E(B,
        smacs=\E(0,

That is, "x" is mapped into whatever the terminal happens to display
for the "x" code after ensuring that the smacs string was sent.

If the terminal does display something different in response to
smacs, we cannot count on any of the acsc codes to be displayed as-is.

> >> # rm -f test ; cc -lcurses -o test test.c ; echo $?
> >> 0
> >>
> >>            at console with TERM set to "xterm0" or in an xterm
> >>            window (which was started as "xterm -tn xterm0 &")
> >>            let's run our test program:

OpenBSD console isn't xterm (and its notion of the alternate character
set depends on its own implementation).

A quick check with ncurses and vttest seems to show it working properly
with line-drawing -- looking at OpenBSD 4.9 console for instance, using
ncurses test-program, menu 'f'.  vttest (screen 3.7) exercises that
differently, and I see that some little-used glyphs such as cr, lf
are just dots.  But overall, the effect is something like a vt220.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

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