Re: Key Curry : Attempting to make it easy to type world languages and orthographies on the web

From: Ed Trager <ed.trager_at_gmail.com>
Date: Wed, 18 Apr 2012 08:33:35 -0400

Hi, Philippe,

Jan Wolter's "JavaScript Madness: Keyboard Events"
(http://unixpapa.com/js/key.html) conveniently summarizes the
craziness involved in dealing with keyboard events and inconsistencies
in key codes, etc.

I am certainly considering whether it will be possible to just use the
characters and not use the key codes; this would indeed probably
eliminate the problems that are bound to occur with non-U.S.-QWERTY
keyboards -- and the problems that still do occur even with U.S.
keyboards due to all the inconsistencies between browsers and even
within browsers on different OSes.

Wolter's section 3.4, "New Standard Key and Character Events"
summarizes the new DOM3 keyboard event standardizations -- Once these
DOM3 is widely implemented in browsers, then I will be able to switch
over to that and simplify the code in Key Curry.

Wolter also laments what a mess has been made of the whole business of
keyboards and key codes. He notes that in the source code he has
looked at, it appears that the browsers generate the key codes from
character values (and, not vice versa) -- and that the browsers assume
a US ASCII keyboard. Well, that is crazy, isn't it?

Unfortunately, since I don't have any AZERTY or other variant keyboard
devices, it's quite difficult for me to generalize what is going on
with key codes using non-U.S. ASCII keyboards.

>
> Also, beware: there are several AZERTY variants. The Belgian > variant is different from the variant used in France (notably in
> the first row).
>

Yes, just read about this yesterday. All these variants scare me!

> You should also know that some ASCII symbols or punctuations are typed
> with AltGr (the RightAlt, which acts in fact like LeftAlt+Ctrl, the
> Cltr key can be the left or right one, but only the left Alt can be
> used to enter character numerically on Windows or type menu
> accelerators), for example these characters :
>  ~ # { | ` \ ^ @ ] }

Yes, this is a problem. Key Curry totally avoids using any "ALT" or
"CTRL" keys. But only the "Pan African" keymap that I designed
considers the possibility of an AZERTY keyboard and provides alternate
entry options for AZERTY. Many legacy keymaps from Yudit also assume
an U.S. ASCII QWERTY layout where you can just type " ~ # { | ` \ ^ @
] " without resorting to extra ALT or AltGr keypresses.

>
> In Europe the Euro symbol is generally placed also on AltGr+E (or
> LeftAlt+Ctrl+E) on most European keyboards, with the exception of the
> British English keyboard where it is placed on the first row.
>
> There's only 1 Alt key on a French keyboard, and on most European
> keyboards, including those using a QWERTZ (German) or QWERTY (British)
> variant; only the default US English keyboard has 2 Alt keys, the
> International US keyboard also features the AltGr key (for typing more
> characters than just plain ASCII) and only 1 Alt key on the left.
>
> Le 18 avril 2012 04:51, Philippe Verdy <verdy_p_at_wanadoo.fr> a écrit :
>> Your input method only needs to detect the characters, don't use the
>> keycodes at all, they are not portable.
>>
>> Note: there are more keys than what you think: not just the A/Q and
>> Z/W pair are swapped, the M is placed on the side of L instead of N,
>> and all punctuation signs are moved, as well as all keys in the first
>> row, plus the <> key on the left of WXCVBN...
>>
>> Don't assume any CTRL, ALT, or AltGr (CTRL+ALT) combination, don't
>> assume the SHIFT key, and beware that the CAPSLOCK mode on a French
>> keyboard is disabled when pressing SHIFT...
>>
>> You don't need keycodes for your input method that just associates
>> pairs of characters (a letter plus a punctuation sign), just use the
>> characters as they are typed.
>>
>> Le 18 avril 2012 03:56, Ed Trager <ed.trager_at_gmail.com> a écrit :
>>> Thank you, Philippe!
>>>
>>> On Tue, Apr 17, 2012 at 8:07 PM, Philippe Verdy <verdy_p_at_wanadoo.fr> wrote:
>>>> Apparently your online input method does not support any other native
>>>> keyboard than a US QWERTY;
>>>
>>> Yes - excellent criticism; and at this time this is unfortunately
>>> true. I thought about this problem when reading French language
>>> materials to research the Pan-African keyboard.
>>>
>>> Originally I thought that the solution to this problem would require
>>> crafting keyboard layouts specifically for AZERTY.  However, I now
>>> think that a much more general solution can be implemented without
>>> needing to actually alter the QWERTY-based keymaps.
>>>
>>> Only a few keys on the keyboard differ between QWERTY and AZERTY, so
>>> it should be possible to just remap those keys (or their key codes) on
>>> the fly in the processing stream.  I would be very happy to discuss
>>> with you how to solve this (off list).  I don't personally have access
>>> to any AZERTY devices and most of the Francophone people I know who
>>> probably use AZERTY are not technically savvy.  However if you and
>>> possibly some other folks on this list or elsewhere have some time to
>>> answer my various questions --and contribute your opinions on what you
>>> think is the correct way that it should work-- then I think it is a
>>> very solvable problem.  Also, if done correctly, such a solution can
>>> be used for other common keyboard layouts beyond AZERTY too.
>>>
>>> - Ed
>>>
>>>> you seem to bond keycodes instead of the
>>>> punctuation characters indicated. E.g. an a French Azerty keyboard
>>>> typing "c;" does not replace it with "ç", you have to type "c$"
>>>> instead (the dollar sign is typed on a French keyboard on the last key
>>>> of the second row, near the Enter key, where the US keyboard maps the
>>>> semicolon).
>>>> Why do you use scancodes to make the compositions ?
>>>>
>>>> It's hard to convince people that your input method is "Pan European"
>>>> if it requires a native US keyboard.
>>>>
>>>> Le 17 avril 2012 23:40, Ed Trager <ed.trager_at_gmail.com> a écrit :
>>>>> A long time in the making, I am finally making "Key Curry" public!
>>>>>
>>>>> "Key Curry" is a web application and set of web components that allows
>>>>> one to easily type many world languages and specialized orthographies
>>>>> on the web. Please check it out and provide me feedback:
>>>>>
>>>>> http://unifont.org/keycurry/
>>>>>
>>>>> In addition to supporting major world languages and orthographies, I
>>>>> hope that "Key Curry" makes it easy for language advocates and web
>>>>> developers to provide support for the orthographies of minority
>>>>> languages -- many of which are not currently supported (or are only
>>>>> poorly supported) by the major operating system vendors.
>>>>>
>>>>> Under the hood, the software uses a javascript user interface
>>>>> framework that I wrote called "Gladiator Components" along with the
>>>>> popular "jQuery" javascript library as a foundation. I have used HTML
>>>>> 5 technologies such as localStorage to implement certain features.
>>>>>
>>>>> Currently, Key Curry appears to work well in the latest versions of
>>>>> Google Chrome, Firefox, and Safari on devices with standard QWERTY
>>>>> keyboards (e.g. laptops, desktop computers, netbooks, etc.). Recent
>>>>> versions of Opera and Internet Explorer version 9 appear to have bugs
>>>>> which limit the ability of Key Curry to operate as designed. The app
>>>>> is not likely to work well on older versions of any browser. I have
>>>>> not yet tested IE 10 on Windows 8.
>>>>>
>>>>> Although Key Curry appears to load flawlessly on the very few Android
>>>>> and Apple iOS tablet and/or mobile devices that I have "dabbled" with,
>>>>> the virtual keyboards on those devices are very different from
>>>>> physical keyboards and I have not yet investigated that problem area
>>>>> at all - so don't expect it to work on your iPad or other mobile
>>>>> device.
>>>>>
>>>>> Constructive criticism and feedback is most welcome. I have many
>>>>> additional plans for Key Curry "in the works" - but I'll leave further
>>>>> commentary to another day!
>>>>>
>>>>> - Ed
>>>>>
Received on Wed Apr 18 2012 - 07:39:19 CDT

This archive was generated by hypermail 2.2.0 : Wed Apr 18 2012 - 07:39:24 CDT