Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]

Hi Cameron,

Cameron McCormack wrote:

> Hi Doug.
> Doug Schepers:
>> Further, when a QWERTY keyboard is remapped to a Dvorak layout, but the  
>> labels on the keys remain unchanged, a typist would expect that hitting  
>> the key labeled "Q" would result in an apostrophe... they would expect  
>> the same behavior if they had bothered switching the keycaps, as well as  
>> remapping.  If they were asked to type "Q" or "q", they would naturally  
>> hit the key that, on my keyboard, is labeled "X".  The same goes for any  
>> remapping, such as when an US keyboard is repurposed to some other 
>> alphabet.
> Of course, but there is already wording in that algorithm to take the
> keyboard layout mapping into account.
>> We've already determined that we can not and should not identify a key  
>> by keyboard layout, i.e. the physical position of the keys; the same  
>> applies to what is printed on the keycap, even more so.
> It’s not what is printed on the keycap that is important, but the
> function of the key subject to the keyboard layout mapping.
> But we are trying to identify a single key, and not what functions it
> may have under different modifiers, yes?
Out of interest, how does the algorithm  take that into account.

for my default layout the keystrokes that normally produce q|Q produce 
ŋ|Ŋ inɛtead, and i need to type AltGr+q/AltGr+Q  to get q|Q

my system input local is en-AU, keyboard driver is customised to 
specific African languages, and physical keyboard is standard qwerty.

I'm curious how the algorithm will handle undefined input locales, or 
keyboard drivers that are forced to use the wrong input locale (which in 
theory is most of the languages in the world at the moment).

As far as i can see there is no way for an application to know what 
keystrokes are being used and extrapolate what character was intended 
from the sequence, esp. if more sophisticated processing and reordering 
is occurring within a driver before the character is past to an application.

At best you might be able to determine what keystrokes are used (maybe 
not always) and what characters are ultimately generated, although 
characters generated may not be in the same order as keystrokes that 
generate those characters.

Andrew Cunningham
Vicnet Research and Development Coordinator
State Library of Victoria
328 Swanston Street
Melbourne VIC 3000

Ph: +61-3-8664-7430
Fax: +61-3-9639-2175

Alt email:

Received on Monday, 30 June 2008 04:18:05 UTC