Re: ACS/UTF-8 Line Drawing Question

[Marc Smith]

Wow, thanks, using setlocale() did the trick -- it works perfectly now
in PuTTY (when combined with NCURSES_NO_UTF8_ACS=1). I truly
appreciate your time and help with this.

--Marc

On Sat, Dec 3, 2016 at 4:55 PM, Thomas Dickey <address@hidden> wrote:
> 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