Re: Need help... trouble writing out wide characters

[Thomas Dickey]

On Fri, Dec 21, 2018 at 01:05:48PM -0600, Bryan Christ wrote:
> Well it turns out that if you setlocale("UTF8") it will work to a point :/

On the command-line, the command "locale -a" shows the values that
you might use -- as environment variables.  The values describe the
locale, but the runtime libraries don't really care about the description
(they match the description with a table that says what it actually
should do).

Just "locale" by itself prints the variables that you are using.

In a _program_, the empty string passed to setlocale tells it to use the
environment variables.

man setlocale:

       If  locale  is an empty string, "", each part of the locale that should
       be modified is set according to the environment variables.  The details
       are  implementation-dependent.   For  glibc, first (regardless of cate‐
       gory), the environment variable LC_ALL is inspected, next the  environ‐
       ment variable with the same name as the category (see the table above),
       and finally the environment variable LANG.  The first existing environ‐
       ment  variable  is used.  If its value is not a valid locale specifica‐
       tion, the locale is unchanged, and setlocale() returns NULL.

> Setting it to en_US.UTF-8 fixed all the problems.  Is there a canonical way
> of setting this?  It occurs to me to read the LANG evn variable but is that
> reliable?
> 
> On Thu, Dec 20, 2018 at 8:00 PM Thomas Dickey <address@hidden> wrote:
> 
> > On Thu, Dec 20, 2018 at 07:35:09PM -0600, Bryan Christ wrote:
> > > I've ported all of my terminal emulator code so that it writes the output
> > > window using mvadd_wch().  Everything works fine including cchar_t types
> > > created by NCURSES_WACS(x).  The problem I'm running into occurs when I
> > use
> > > setcchar() to construct a cchar_t.  As long as the value I stuff into
> > > wch[0] is basically low ascii (or ACS), it displays just fine.  Whenever
> > > the value is actually utf8 encoded, I typically see a glyph in the window
> > > that looks like a question mark inside a solid circle.  Skipping over
> > lots
> > > of irrelevant stuff, my debug code is basically:
> > >
> > > wchar_t      wch[] = { 0xE29480, 0x0000 };
> >
> > That's asking for Unicode U+E29480
> >
> > https://www.fileformat.info/info/unicode/char/2500/index.htm
> >
> > hints that you're thinking of UTF-8.
> >
> > You can pass the UTF-8 bytes (assuming that your locale encoding _is_
> > UTF-8)
> > via addch in ncurses:
> >
> >
> > https://invisible-island.net/ncurses/man/curs_addch.3x.html#h3-Character-Set
> >
> > If you want to make it portable to "any" X/Open Curses, you'd have to
> > convert the 3 bytes into a wide-character, e.g., using mbrtowc or
> > mbsrtowcs,
> > and pass _that_ to add_wch
> >
> > Interesting, SVr4 curses (reading the Illumos source-code) allowed
> > multibyte characters via addch.  But X/Open says
> >
> >         addch, mvaddch, mvwaddch, waddch - add a single-byte character and
> >         rendition to a window and advance the cursor
> >
> > > setcchar(&my_cchar, wch, 0, 0, NULL);
> > > mvadd_wch(window, y, x,  &my_cchar);
> > >
> > > Now that's above is the debug code.  If I don't hard-code what's in wch
> > and
> > > let the CSI interpreter do it's thing, what I see is a bunch of q's, x's,
> > > w's, etc... that you would normally expect to see in ACS mode when it's
> > not
> > > being properly handled.
> >
> > --
> > Thomas E. Dickey <address@hidden>
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
> >
> 
> 
> -- 
> Bryan
> <><

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

signature.asc
Description: Digital signature