Re: bug: ncurses + slackware 10.0, 10.1

[Thomas Dickey]

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
> console)?

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);
> #else
>    mvaddch (i / 32, i % 32, (i >= 32 && i < 127) ? i : i | A_ALTCHARSET);
> #endif
>  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 @@
>     }
>   #endif
>   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
http://invisible-island.net
ftp://invisible-island.net