Hello all,

   Just got an inquiry recently about a problem in my Win32a
flavor of PDCurses,  which has led to a more general PDCurses

   The inquiry came from a gent using a Swedish keyboard layout.
Win32a was insisting on treating it (at least partly) as being
on a US layout.  I think I've worked through these problems.

   There were also some issues in how extended ASCII (characters
128 to 255) were rendered.  Swedish uses characters such as
"a-ring" (a with a small ring over it),  a-umlaut,  and o-umlaut.
Accented characters such as these (and similarly accented
characters in French,  Italian,  etc.) were shown completely
wrong.  I'd shown extended ASCII using the old DOS/IBM encoding,
and realized they really ought to be shown in Latin-1.

   Which leads to a problem.  The plain ol' console flavor of
Win32 uses DOS/IBM encoding.  If you've a Swedish layout
and hit a-ring,  a-umlaut,  and o-umlaut,  getch() returns
0x86, 0x84,  and 0x94.  Output those same values on screen
using addch(),  and you get a-ring,  a-umlaut,  and o-umlaut;
i.e.,  DOS/IBM encoding is consistently used.

   Do the same in Win32a,  and those values become 0xe5,  0xe4,
and 0xf6,  following the Latin-1 (and Unicode) values.

   Which leads,  at last,  to my question.  Is there any particular
character encoding associated with PDCurses?  (Presumably the
IBM/DOS encoding.)  If one hits,  say, a-ring on a Swedish keyboard
layout,  is it "acceptable" for getch( ) to return 0x86 on one
PDCurses implementation,  but 0xe5 on another?

Thanks!                  -- Bill

Reply via email to