Hello all, Just got an inquiry recently about a problem in my Win32a flavor of PDCurses, which has led to a more general PDCurses question.
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
