>> Is there any particular character encoding associated with PDCurses?

No. In the case you're talking about, the input comes from
ReadConsoleInput(). It's Windows itself that determines the active
console code page. (The tables in win32/pdckbd.c are all just for
things like ALT and function keys.) You could set it to a so-called
ANSI page if you wanted.

   Thank you;  this does clear things up.  With a little experimenting,
this is all starting to making sense to me.  With the current Win32
scheme,  it looks as if one could switch to,  say,  Russian,  and have
Russian text entered and displayed.  In theory,  my Win32a version
should be able to do the same thing. After which,  I think the only
internationalization issue would be bi-directional text for Hebrew,
Arabic,  etc.  I'll leave that problem for another day.

The exception is if you're using the WIDE build. In that case, you
always get Unicode. That's actually what I'd recommend.

   I'm increasingly seeing why.  Handling 8-bit chars has all sorts
of strange nuances to it I'd not fully appreciated before.  Though
I think,  between your replies and some testing at my end,  I'm
seeing how to get all this to work... it'll probably result in an
update to Win32a in the next few days.

> I should add, there is one issue with this: The box-drawing
> characters. In the Win32 console port, these are defined in terms of
> CP437 -- both because that's the default console code page (for the
> U.S.), and because there aren't any box-drawing characters in the
> "ANSI" code pages. But this problem is obviated if you use the WIDE
> build.

   Also obviated in Win32a.  If the A_ALTCHARSET flag is set,  we
know to show a suitable Unicode character.  The actual display of
text is handled using TextOutW (wide-char function) even in the
non-WIDE build.  So at least I don't have that problem to fix as well.

Thanks!              -- Bill

Reply via email to