From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Dec 29 2003 - 20:37:23 EST
From: "Michael (michka) Kaplan" <michka@trigeminal.com>
To: "Unicode List" <unicode@unicode.org>
> 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?
This archive was generated by hypermail 2.1.5 : Mon Dec 29 2003 - 21:20:27 EST