Re: ACS/UTF-8 Line Drawing Question

[Thomas Dickey]

On Sat, Nov 26, 2016 at 08:37:30PM -0500, Thomas Dickey wrote:
> On Mon, Nov 21, 2016 at 09:25:29AM -0500, Marc Smith wrote:
> > On Fri, Nov 18, 2016 at 9:03 PM, Thomas Dickey <address@hidden> wrote:
> > > On Thu, Nov 17, 2016 at 10:01:51AM -0500, Marc Smith wrote:
> > >> Hi,
> > >>
> > >> I'm following up on this to see if you had any additional advice --
> > >> I'd really like to make PuTTY work out-of-the-box. Currently, users of
> > >> my software must change the remote character set to "Latin-1, West
> > >> Europe" when using PuTTY in order for the line drawing characters to
> > >> display properly. No other terminal emulators that I've come across
> > >> have this issue.
> > >>
> > >> My TUI application is using the CDK library. Does
> > >> "NCURSES_NO_UTF8_ACS=1" not affect this? I believe CDK uses everything
> > >> via ncurses, but maybe something related to the line drawing is
> > >> implemented differently? I'm out of ideas, so any help would be
> > >> greatly appreciated.
> > >
> > > three points come to mind (though I seem to recall pointing out 
> > > another...):
> > >
> > > a) CDK would have to be linked with ncursesw (if not, you would get ASCII
> > >    +'s and -'s for lines)
> > 
> > CDK is in-fact linked again ncursesw, and actually, on this system,
> > there is only ncursesw. I am getting x's for the vertical lines, and
> > q's for the horizontal lines.
> > 
> > 
> > > b) NCURSES_NO_UTF8_ACS should work - but setting it in PuTTY's environment
> > >    variables dialog doesn't help much if the server disallows that 
> > > variable.
> > 
> > I'm setting NCURSES_NO_UTF8_ACS before the TUI binary is executed. I
> > seem to recall even verifying the value is set with getenv() at one
> > point.
> > 
> > 
> > > c) Someone might still be running RHEL5 (which used a version of ncurses
> > >    before the variable was added).
> > 
> > This system is using ncurses 5.9.
> 
> hmm - I see.  I was thinking from the ncurses library aspect (whether
> the library supports the variable).  On my CentOS 7 machine, my
> directory editor does line-drawing properly and is linked with ncursesw.
> 
> But in a quick check of cdk - that (though linked with ncursesw) doesn't
> do line-drawing.  I'll investigate that.

The problem which I see in cdk is simple:

        + all of the examples call initscr directly without first calling
          setlocale, e.g.,

                /* Set up CDK. */
                cursesWin = initscr ();
                cdkscreen = initCDKScreen (cursesWin);

        + The ncurses library checks the locale during initialization (e.g., in
          initscr), and decides whether to use UTF-8 directly or use the VT100
          line-drawing (which is what the terminal description provides).

        + while CDK does call setlocale in initCDKScreen, that's too late
          for the initialization-check.

So... you can fix your application using

        #include <locale.h>

        setlocale(LC_ALL, "");

before the initscr() call.

Since none of the applications actually use the return-value from initscr(),
I'm thinking that the nice(r) way to improve CDK would be accept a null
pointer for the parameter of initCDKScreen, and checking if initscr was
called before.

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

signature.asc
Description: Digital signature