From: "Michael (michka) Kaplan" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]>
> Such a format for Windows would be quite inadequate since it is missing many > things, such as: > > 1) The version of Windows in which it first shipped (there were minor > differences in what was in 9x vs. NT, and on NT some characters were added > to keyboards in later versions). If the intent is to display in a user interface which keystroke the user must press to create a character sequence it can be useful to know the character generated in the default state without modifiers (or the character generated in CAPSLOCK mode). This is an issue for example when creating "accelerators" or keyboard shortcuts in an application and one wants to display this shortcut in menu items or in button tooltips. (For example, how do you display the "mnemonic" in Java menu items, or the "&"-selected character in Windows resources, fo menu items that display non Latin strings such as Chinese or Arabic? You need to display it at end of the menu item, and the underlined convention for mnemonics is not usable. But which string will you display? You need this information support from the keyboard driver itself or an OS API). Designing keyboard shortcuts that will work in internationalized applications is a difficult problem for the localization of applications, and there's no way to do it without knowing the exact keyboard layout actually used, but that may not be knowed precisely at run-time, or may be customized by the user. Not supporting shortcuts is also a problem for accessibility. Unfortunately, Windows does not help the application to select appropriate shortcuts to use to match some prefered "accessible characters present in menu items. There's no automatic generation of these shortcuts from menu item strings, and no automatic display. > 2) The fact that many keystrokes produced more than one keystrokes (called > ligatures there athough the technology can apply to code point combinations > that do not, in fact make up ligatures) I suppose you speak about complex keyboards that generate variable-size sequences of characters from multiple keystrokes, using complex input methods, such as Pinyin input method editors for Chinese. > 7) No way to explain SGCAPS use of the CAPS lock, used by Hebrew, Czech and > others. Also the Swiss German keyboard... > 8) No way to describe "custom" shift keys like seen in the [unfortunate] > Canadian Multilingual Standard keyboard Do you mean here a sort of a second AltGr modifier mapped onto an OEM key? Or about the many dead keys it supports to enter accents used in various languages? > I could go on. but you get the idea. There is no simple list because there > is no simple format that can describe them. Notably the complex keyboards that support multiple scripts or large scripts: would you show Kangxi radicals on a Chinese keyboard used with a ideographic radical composition mode, or the ASCII keycap in the Romaji mode of a Japanese keyboard?
