From: Doug Ewell (dewell@adelphia.net)
Date: Tue Dec 30 2003 - 01:16:12 EST
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/
This archive was generated by hypermail 2.1.5 : Tue Dec 30 2003 - 02:03:59 EST