[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug: ncurses + slackware 10.0, 10.1
Re: bug: ncurses + slackware 10.0, 10.1
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
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
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
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
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
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).
int main ()
for (i = 32; i < 256; i++)
mvaddch (i / 32, i % 32, i | A_ALTCHARSET);
mvaddch (i / 32, i % 32, (i >= 32 && i < 127) ? i : i | A_ALTCHARSET);
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 |
A_ALTCHARSET : ch;
Thomas E. Dickey