Dave,
My point was that it was stupid to make the field so small. Since the ID is
burned into the KB prom to indicate the layout other circumventions are a
kludge.
Carl
-----Original Message-----
From: David_Possin@i2.com [mailto:David_Possin@i2.com]
Sent: Wednesday, October 03, 2001 1:59 PM
To: Carl W. Brown
Cc: unicode@unicode.org; unicode-bounce@unicode.org
Subject: RE: Deseret keyboard (was:Re: Special Type Sorts Tray 2001)
Carl, Peter,
When I was testing i18n Win98 I hooked up different language USB keyboards
plus the default keyboard using the normal connector and after adding the
locales in the Keyboard Settings I was able to type with all keyboards
according to the locale settings in their respective different languages.
Yes, we can't predefine all locale-keyboard variants, but we could create
special layouts and assign them to a locale variant. So at least I see the
option to be able to map a subset of language variants and their keyboard
layouts to the keyboard language recognition drivers. Ok, somebody would
have to hack the .VXDs to replace the hardcoded mapping, but it isn't that
much of a task. I poked bits into them to switch the recognized locale to
automate the testing of all supported keyboards, comparing created character
by key code with the defined character for that location.
So I see no big issue adding a Deseret and a Klingon keyboard in a daisy
chain with a German and a US keyboard. It would just be nice if users could
create sig's to define the layout. Now all I need is the Klingon font,
thanks to this thread I found the Deseret font.
- Dave
"Carl W. Brown" <cbrown@xnetinc.com>
Sent by: unicode-bounce@unicode.org
10/03/01 02:32 PM
To: <unicode@unicode.org>
cc:
Subject: RE: Deseret keyboard (was:Re: Special Type
Sorts Tray 2001)
Peter,
I was the chairman of the keyboard standards committee for ACCESS.bus
which was the predecessor the USB. However Intel got impatient and
developed the USB standard. Unfortunately they only reserved 8 bits for the
keyboard language identifier. Had they done a better job you could really
use the field in the device driver and be able to use two keyboards with
different keyboard language layout codes. I am not clever enough to figure
out how to encode 6700 language in 8 bits. It is even worse because you can
have different language layouts. For example there are several very
different French keyboard layouts. The multiply it by the non-language
variants such as numeric keypad layout or function/ime/special keys
With a $10 keyboard it would be easy to plug in another keyboard when you
needed to type in the language or have two keyboards in different languages
plugged in at the same time.
Carl
-----Original Message-----
From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]On
Behalf Of Peter_Constable@sil.org
Sent: Wednesday, October 03, 2001 11:11 AM
To: unicode@unicode.org
Subject: Re: Deseret keyboard (was:Re: Special Type Sorts Tray 2001)
On 10/03/2001 10:48:29 AM John H. Jenkins wrote:
>Getting screen shots of my Deseret keyboard layout is a less than
>trivial task, so I'll try to describe it word-wise...
Except for the Caps Lock behaviour, this layout would be fairly
straightforward to setup for Windows using Keyman. A few stored arrays and
three rules ought to do it:
+ [K_Q] > deadkey(1)
+ any(RegKey) > index(RegChar,1)
deadkey(1) + any(DK_Key) > index(DK_Char,2)
Keyman 5 doesn't provide a way to make keystrokes sensitive to the caps
lock state. But the English QWERTY keyboard is really a distinct keyboard
layout, and I would be more inclined to have a Deseret layout be Deseret
only and get users to switch to an English QWERTY keyboard (or whatever
other keyboard they might want to use) rather than mix two different writing
systems into a single layout using the Caps Lock state to switch between
them.
This archive was generated by hypermail 2.1.2 : Wed Oct 03 2001 - 16:14:31 EDT