Adam Twardoch <list dot adam at twardoch dot com> wrote: > Do you know if there are human-readable versions of Windows and/or > MacOS keyboard layouts available somewhere? > > I'm looking for a way to compile a table that could look a bit like > the following: > > Platform Language Layout Unicode Keystroke > Windows Polish Polish (Programmers) 0105 AltGr+A > Windows Polish Polish (Programmers) 0041 A > ... > > where I could, for example, look up which exactly keyboard layouts let > the user input, say, a with acute, and how he can do that.
and Michael (michka) Kaplan <michka at trigeminal dot com> responded: > Such a format for Windows would be quite inadequate since it is > missing many things, such as: I was sorry to see Adam's idea shot down so quickly, because it seemed like a pretty good thought to me, assuming the practical limitations are understood. Michael is right, of course, that the differences between keyboards amount to more than just the basic layout and Shift and AltGr keys. There are custom shifting keys, dead keys, and unusual uses of Caps Lock, not to mention Far Eastern IMEs. But I don't think the whole idea needs to be scuttled because of these problems. Let's see if we can expand Adam's chart to cover some of these extra needs. > 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 this is really necessary -- aren't updated drivers available? -- it can be added as another column. > 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) The "Unicode" column in Adam's table would have to allow combinations of code points. Keyboards for Indic scripts, in particular, frequently have keys that generate at least three Unicode characters. This is the "1-to-many" problem. > 3) The fact that in many cases combinations of keystrokes produce a > single code point (called dead keys) -- best described by the many > combining characters that go with individual base characters Similarly, the "keystroke" column would need to be expanded to handle sequences of keys. This is the "many-to-1" problem. > 4) No completely consistent description of OEM keys that is based on > letters that would work for all keyboard hardware If Michael means what I think he means, the solution is to use ISO 9995 terminology (at least for the basic letter-generating keys, if not for shifting keys). Don't say "A" for the keystroke, say "C01" (or "D01" if you're talking about a French keyboard). It's really not that hard to get used to this naming convention. > 5) Naming inconsistencies between different versions (rare but present > on occasion) You mean the name of the keyboard layout? Any examples that would make the list unusable? > 6) No good way to explain when CAPS lock is being used for casing, > etc. Good point. I remember hearing that German keyboards don't use Caps Lock the same way U.S. keyboards do; apparently they apply Shift to all keys, not just letters. I don't know how to handle this, but I'll bet someone could figure it out. > 7) No way to explain SGCAPS use of the CAPS lock, used by Hebrew, > Czech and others. Can't comment, since I'm not familiar with this issue. > 8) No way to describe "custom" shift keys like seen in the > [unfortunate] Canadian Multilingual Standard keyboard Instead of saying "AltGr+A", assign one column to each special shifting key. And so on. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
