Re: Ncurses, UTF-8, Centos and box characters

[Thomas Dickey]

On Thu, Feb 12, 2015 at 01:25:27PM -0000, Paul D Smith wrote:
> Dear Ncurses gurus,
> 
> Am I misunderstanding ncurses or is there a fundamental flaw in box character
> handling?  Perhaps you could read on and comment?
> 
> What I am finding is that I do not seem to be able to write an ncurses based
> program that can simultaneously handle UTF-8 based boxes and old (vt100)
> style boxes.  In order to get box characters on a UTF-8 system I have to:
> 
>   a.. link with ncursesw (seems reasonably) 

true (plain ncurses can't do UTF-8)

>   b.. call wborder() and not box() or border() (seems unreasonable) 

actually, I use all three of those in my test-programs, and they work
for me with UTF-8 (but see NCURSES_NO_UTF8_ACS in the manpage).  If your
locale-encoding is UTF-8, ncurses will still prefer vt100 line-drawing
unless told by that environment variable not to use it (linux, screen
for instance).

X/Open (and SVr4 curses), by the way, insists that wide-characters go
only via the wide-character interfaces.  ncurses went past that in the
1990s, without noticing.  So you can use printw with UTF-8 strings, and
generally get something useful.  (There's a limitation on moving the
cursor around in the middle of writing multibyte/multicolumn characters,
but it's a corner case - and far away from line-drawing).

>   c.. specify characters such as WACS_VHLINE and not ACS_VHLINE.
> This all seems very contrary to the concept of original curses which (and I 
> last used curses 25 years ago!) was to be able to write, compile and run a 
> single program that would run on any terminal type for which a TERMCAPS entry 
> was possible.  So it didn’t matter whether I was using a vt100, vt220, 
> tektronix or Wyse terminal, the same program ‘just ran’ and did the best it 
> could to look pretty.
> 
> I was expecting UTF-8 support to act in a similar manner with a single 
> program now adding UTF-8 as effectively a variant of whatever terminal type I 
> might have and, more importantly, I should have minimal understanding of 
> ‘'UTF-8/not-ness in my program throughout the development process.
> 
> What I was expecting was that:
> 
>   a.. If I link with ncurses, I get no UTF-8 support (why bother?!) 
>   b.. If I link with ncursesw I get UTF-8 support (surely you would 
> always...) 
>   c.. If the locale support indicates UTF-8 then under the covers 
>     a.. ACS_VHLINE is mapped to WACS_VHLINE (and there is in fact no need for 
> the WACS_ macros) 

X/Open lists them, so ncurses provides them :-)

>     b.. All functions such as box() are mapped to wbox() and similar (which 
> are only internal functions)
>   d.. There are no wborder() or similar functions because border() is mapped 
> to old (7-bit) or wide functions under the cover based on locale 
>   e.. Possibly a belt-n-braces option that can be set (environment variable 
> and/or something that can be passed in via a command line argument to the 
> parent program) to force UTF-8 support on/off.
> So, is ncurses UTF-8 support really the mess I think it is, or what did I 
> miss?

As I said, it's been working for me.  If I'm using PuTTY, I set the
environment variable (NCURSES_NO_UTF8_ACS).

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

signature.asc
Description: Digital signature