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 19:12:08 -0400 (EDT)

On Sun, 11 Sep 2011, Alexei Malinin wrote:

Thomas Dickey wrote:
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.

These sentences are unclear for me. In my test terminal description
I wrote that ACS_VLINE should be displayed as "|" (ASCII decimal 124).
Please see below.

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.

I understand you. But I think that the same behavior of the "test" program
for Linux and OpenBSD does not say about terminal implementation issues.

Well, I was testing on an OpenBSD console, since that's what I thought
you were referring to.  Linux console is, again - different from both
xterm and OpenBSD console.  Someone could spend time and document the
expected behavior for all of those...

Please explain me the difference between "!" (ASCII decimal 33) and
"|" (ASCII decimal 124) in these terminal descriptions (look at "acsc"):

testterm0|vt100 subset 0,
       am, km, mc5i, npc, nxon, xenl, xon,
       cols#80, it#8, lines#24,
       bel=^G, clear=\E[H\E[2J$<50>, cr=^M,
       cup=\E[%i%p1%d;%p2%dH$<5>, ed=\E[J$<50>, el=\E[K$<3>,
       el1=\E[1K$<3>, enacs=\E(B\E)0, home=\E[H$<5>, ht=^I,
       ind=^J, nel=\EE$<2>, rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O,
       rmso=\E[m$<2>, rs2=\Ec$<50>,
       sgr=\E[m$<2>%?%p1%p3%|%t\E[7m$<2>%;%?%p9%t\016%e\017%;,
       sgr0=\E[m$<2>\017, smacs=^N, smso=\E[7m$<2>,
       acsc=q-x!,
testterm|vt100 subset 1,
       am, km, mc5i, npc, nxon, xenl, xon,
       cols#80, it#8, lines#24,
       bel=^G, clear=\E[H\E[2J$<50>, cr=^M,
       cup=\E[%i%p1%d;%p2%dH$<5>, ed=\E[J$<50>, el=\E[K$<3>,
       el1=\E[1K$<3>, enacs=\E(B\E)0, home=\E[H$<5>, ht=^I,
       ind=^J, nel=\EE$<2>, rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O,
       rmso=\E[m$<2>, rs2=\Ec$<50>,
       sgr=\E[m$<2>%?%p1%p3%|%t\E[7m$<2>%;%?%p9%t\016%e\017%;,
       sgr0=\E[m$<2>\017, smacs=^N, smso=\E[7m$<2>,
       acsc=q-x|,

With "testterm0" (for example, run "xterm -tn testterm0") the "test"
program correctly displays a box with "!" as ACS_VLINE, but with
"testterm" ("xterm -tn testterm0") the "test" program displays a box
with garbage as ACS_VLINE!

I cannot understand the difference between "!" (ASCII decimal 33) and
"|" (ASCII decimal 124)!

I think it would be helpful if you had a copy of the ncurses test-program
and explored menu 'b' with the A/a toggles while scrolling the data left/right. I didn't record it all, but have the impression that the
96-characters are mapped into some smaller set.  If that's correct, then
"!" just-happens to fall into a nice mapping, while "|" does not.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



reply via email to

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