Myths about keyboard layouts

We hear many misconceptions about keyboards and what they can do. This section will hopefully clear up a few of these.

Myth #1 - 'I get the feeling Microsoft just makes up these keyboards by themselves. Why don’t they represent my language the way I expect them to?'

New keyboards for a market always get tested in their respective market. A great deal of research does go into the keyboards shipped with the system, with feedback from linguists, government officials, other internationalization experts, and local software providers. Often it is the case of Becker’s law applying (that is, for each expert, there is an equal and opposite expert), unfortunately.

Myth #2 - 'I don’t like the keyboard layout Windows ships for my language; can we remove it or change it?'

In an ideal world, customers could customize their keyboard infinitely (and there are some projects out there that will simplify this process) but due to backward compatibility, we cannot simply remove a keyboard or change keys. There are simply too many customers who count on consistent behavior across releases (even if the behavior is not ideal). In addition, while a customer may not like the keyboard, this may be a national standard for the language, and there may be a requirement to support this particular keyboard. There are a number of other input options to help users input characters not on their keyboards, including:

• Character Map (available from Accessories|System Tools)
• The Insert Symbol Dialog (available in Office)
• The ALT+X option, also available in Office. (Typing ALT+X after a character gives you the Unicode value; typing ALT+X after a Unicode value gives you the character)

Myth #3 - 'I want to make sure I have every single visual variant of my characters on the keyboard—the canonical (or isolate) version of the code point is not sufficient.'

Keyboards on Windows only deal with code points, not with glyphs. Code points are used exclusively for text processing, except for display. At the point of display, technologies such as fonts and rendering engines map between code points and glyphs. There is an important technical boundary between code points and glyphs, and this exists in order to maintain at least modicum of simplicity within the system. (Imagine if every single visual variant of a code point had to be maintained for text processing!) For this reason, keyboards focus exclusively on code points, and leave the work of linking code points to the appropriate visual display to fonts and shaping engines.

Myth #4 - 'I want to have an IME rather than a keyboard for my language.'

This is generally heard from customers working with complex script languages who feel that they need to have all visual variants of a code point on an input method. Input Method Editors really make sense with ideographic languages such as Chinese or Korean, where there are literally thousands of characters needed for the language. Each of these ideographic characters is semantically distinct. Compare this with complex scripts, where the number of semantically distinct characters is generally less than 100, but the number of visually distinct characters is considerable (into the hundreds). Again, keyboards work with code points, not with glyphs. Since code points are semantically distinct and not visually distinct, a complex script language can easily be handled via a keyboard; as noted earlier, the code points are linked to the appropriate visual display by other non-keyboard technologies.