[Top][All Lists]

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

Re: bug: ncurses + slackware 10.0, 10.1

From: Thomas Dickey
Subject: Re: bug: ncurses + slackware 10.0, 10.1
Date: Sun, 10 Apr 2005 19:16:57 -0400 (EDT)

On Sun, 10 Apr 2005, Frank Heckenbach wrote:

Russell Whitaker wrote:

Program below illustrates a bug: lower case a,  lower case f thru z,
and number 0 are printed with graphic characters. This bug did not
appear in earlier versions of slackware.

With the given example, I see a difference which I assume is what you're
talking about: if I run the sample in Linux console, linked against ncurses 5.4 (or current), I'm seeing the cells 32-127 as line-drawing.
(Cells 0-31 are control characters, and are blank).

Running against ncurses 5.3 or earlier, I don't see line-drawing.

In each case, cells 128-255 are displaying the PC-specific font (some
double-width lines, etc).

However, running in xterm (screen actually), I do see line-drawing for
ncurses 5.0, 5.2, 5.3, 5.4 in the same positions.

Reading the sample code, I would expect to see line-drawing characters
(in contrast to the normal font) for each case.

Since the difference is in how cells 32-127 are displayed, I assume that's
the issue.  (Though the comments about direct access to the PC font are
a little confusing to me...).

AFAICS, something was changed WRT A_ALTCHARSET. With previous
ncurses versions, one could (apparently) get direct font access with
this attribute (e.g. IBM PC character mapping if such a font was
loaded, at least on the Linux console). Now some ASCII characters
have been redefined with A_ALTCHARSET.

I agree with part of this. The part that I don't agree with is the assumption that setting A_ALTCHARSET would in some cases not try to use the terminal's alternate character set. (The sample code sets it in every cell).

There is a change to the way A_ALTCHARSET is handled. That was done to make the line-drawing work with UTF-8 environments. Essentially what happens is that the acsc string's information is not used until ncurses is ready to write it to the screen. Before 5.4, that table lookup was done earlier (and was inconsistent). The inconsistency and early evaluation meant that I couldn't decide to use a UTF-8 line-drawing character as needed.

Usually that's only important to people using the contents of acs_map[],
and assuming that it contains the mapped value.  (I've seen 1-2 complaints
about that).

This problem is related.  Earlier there was no mapping that resulted
in codes 32-127.  Linux console's acsc maps to codes in the 128-255 range.

It sounds as if you're expecting that passing 37|A_ALTCHARSET wouldn't try to display that character in the alternate character set.

While it's possible that I removed some check within waddch() which told it to strip off A_ALTCHARSET when no mapping exists in acsc, I don't recall that as something I did intentionally. More likely (I'll have to study that), it was lost in the changes to PutAttrChar(). Making it so
you could only write the characters described in acsc would not be a good
idea though.

I don't know if the change was intentional (but it appears so,
looking at tinfo/lib_acs.c:84-116 in 5.4) or whether A_ALTCHARSET
was ever intended to mean what I supposed it did.

I've always interpreted it as saying to try to use the alternate character
set.  But acsc tells it what characters to map.  And barring a UTF-8
locale that suggests that all of the line-drawing characters are available, I'd assume that the characters available for mapping might
be limited to those described in acsc.

Anyway, the affected characters are all printable ASCII characters
which are the same, at least in the IBM PC character mapping and
probably most other fonts, so if necessary I could just turn off
A_ALTCHARSET for those characters (#if 0 in the example below).

yes - that sounds right.

Bear in mind that you're actually using the smpch/rmpch feature, which
happens to work because smacs/smpch and rmacs/rmpch are the same strings.
I seem to recall that long ago ncurses had something like A_PCCHARSET
to distinguish these, but since it was not part of X/Open curses, that
was dropped.

Is this the recommended thing to do, or is there another way to get
direct access to all characters of the underlying font (on the Linux

As I understand the issue yes (though actually there's underlying font for cells 32-127, which you don't seem to want).

#include <ncurses.h>

int main ()
 unsigned i;
 initscr ();
 for (i = 32; i < 256; i++)
#if 1
   mvaddch (i / 32, i % 32, i | A_ALTCHARSET);
   mvaddch (i / 32, i % 32, (i >= 32 && i < 127) ? i : i | A_ALTCHARSET);
 getch ();
 endwin ();
 return 0;

If so, Russ, you could try this patch (touch crt.pas after applying
to force recompilation):

--- units/crtc.c.orig   Sun Apr 10 23:18:13 2005
+++ units/crtc.c        Sun Apr 10 23:20:27 2005
@@ -2694,7 +2694,7 @@
  if (!pccs && !_p_IsPrintable (ch)) return ' ';
-  return (crt_LinuxConsole && pccs) ? ch | A_ALTCHARSET : ch;
+  return (crt_LinuxConsole && pccs && (ch < 32 || ch > 126)) ? ch | 

Thomas E. Dickey

reply via email to

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