• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


Remapping for Foreign Letters

Page history last edited by PBworks 17 years, 2 months ago


Home > Remapping > Remapping for Foreign Letters & Symbols


To learn more about generating international symbols or letters, go to http://www.AlphaGrips.com/characters.html.

Specific Remapping for Foreign Letters & Symbols Page:



Character Frequency Analysis

From: Matthias Schult Date: Sun, Apr 30 2006 7:09 pm

On Sun, 30 Apr 2006 09:34:05 +0100 Toby Dickenson wrote:


> You didnt make any comment on design method...... I have been planning a

> similar exercise using this as a starting point:

> http://www.visi.com/~pmk/evolved.html


That's exactly what I intended to do. Thanks for pointing out that web page. With the AG we have the advantage that for most keys the fingers don't have to move at all. On the other hand I don't believe it is a good idea to optimize a layout for one specific language. Most people are not native English speakers and especially dealing with computers many will switch a lot between their mother tongue and English for example. There are language boarders everywhere too, just look at Europe.


> Neither would it be good with alternation every letter. Dvorak places several

> common digraphs (such as 'th') on adjacent keys under the same hand. Typing

> "pith" (left-left-right-right) is more comfortable than

> "late" (right-left-right-left)


Right, that's the problem. How to find a decent compromise between putting digraphs on one hand and equal hand usage? an, en, and er are common digraphs in most languages, but a,e, and r make up 21% of all typing already (including space, punctuation, and special characters); and if we see that "e " is actually an internationally even more common combination and almost 14% of a text are spaces (16% in English), we soon have a problem. The 6 most common characters of a language (in English {Space}, a, e, t, i, and o) make up 50% of all text. That seems to be universally valid. Digraphs and trigraphs are also heavily language dependent. If you find a lot of "th" in a text, it's probably English. If you see a lot of "ch" and "ei" and "ie" and even "sch" it's German. And with "nh", "th", and "ch": Vietnamese.


First I'd try to find out which characters should be on the 24(?) home row keys. Then divide into left and right hand. Right now I'd say we give a penalty for each hand switch and make a penalty for unequal hand usage. This penalty could be distributed like {a * exp(- x²/(1 - x²) ) * exp(- b * x²)}. As you said it would be very nice to have some reasoning for choosing the width and height of the distribution.


{supplement:} I just came up with the following reasoning: The standard deviation of the distribution should be the average work distribution between the hands using a random letter distribution. It's not easy to calculate that, and I have no clue right now what the result will be.


For the test text I'd leave away all languages and dialects which are usually not used for writing:

luxembourgish_lb (?)



kurdish_ku (? written in arabic in Iran and Iraq; usage was restricted till 2002 in turkey, small part of Syria. So I guess the latin alphabet is usually not used for writing.)







tatar_tt (? uses mostly the cyrillic alphabet)

min_nan_zh-min-nan (? usually written in chinese characters)



waray-waray_war (?)



scots_gaelic_gd (?)



Neglecting also artificial languages (Esperanto, Ido, Interlingua) and dead languages (Latin). Leaving:



language amount of text speakers language family
english_en 2845571442 470 germanic
spanish_es 269538836 362 italic
portuguese_pt 163812785 182 italic
indonesian_id 30817378 140 malayo-polynesian
french_fr 558925974 124 italic
german_de 1128049793 121 germanic
javanese_jv 1197566 76 malayo-polynesian
vietnamese_vi 24035758 67 mon-khmer
italian_it 260198406 63 italic
turkish_tr 39983689 59 turkic
polish_pl 287792245 44 slavic
romanian_ro 33147565 26 italic
serbo-croatian_sh 7494274 21 slavic
dutch_nl 266594403 21 germanic
azerbaijani_az 1276922 21 turkic
tagalog_tl 2649370 15 malayo-polynesian
hungarian_hu 65426119 15 finno-ugric
cebuano_ceb 863257 15 malayo-polynesian (?)
czeck_cs 57663394 12 slavic
swedish_sv 130327751 9 germanic
finnish_fi 93787778 6 finno-ugric
danish_da 43996924 5 germanic
norwegian_bokmal_no 74809291 4 germanic
lithuanian_lt 20014862 4 baltic
latvian_lv 5061632 1.6 baltic
estonian_et 24406323 1.1 finno-ugric
slovak_sk 32338079 slavic
haitian_ht 363879 italic
catalan_ca 47349432 italic
galician_gl 23843558 italic (?)
slovene_sl 29198388 slavic
faroese_fo 1172743 germanic
afrikaans_af 7916993 germanic (?)
norwegian_nynorsk_nn 15903664 germanic
irish_ga 3542912 celtic
bosnian_bs 12145269 slavic
islandic_is 9439568 germanic
croatian_hr 25977897 slavic
welsh_cy 3682368 celtic
basque_eu 4296053 isolated (?)
albanian_sq 5484695 isolated


I'm not sure about including some of them (marked with "?"). Should they be weighted differently?


If all goes well, I'll have a web space next weekend to make everything available online next weekend (when I'll hopefully have an AG as well.)

Foreign characters in Linux – Question & Answer

Foreign characters in Linux – question

From: jmacz Date: Thurs, Jun 22 2006 7:11 pm

… I've been searching around for a way to include latin characters through the combinations of keys without luck.


At this moment my old latin keyboard (and in consecuence, the AG-5) have an ES layout. This means that all the symbols one should get with the green and red shifts have change their place within the AG-5. After trying by brute-force all the possible combinations I was able to identify where the main symbols were, but I've lost | # [] {} (which I need for basic linux console administration and occasional programming) and have not been able to "produce them" by any means.


I followed the conversations in:








and tried the second Didger's post without luck. Appart from changing "/usr/share/X11/xkb/symbols/us" or "/usr/share/X11/xkb/symbols/es" - in my case, and restarting the X server, is there somthing else I must do?


What I would really want is to modify the default US layout and include there the vowels with accent (áÁéÉíÍóÓúÚàÀèÈìÌòÒùÙ) and ñÑ (perhaps çÇ too - I'd like to learn french :-)).


Is this possible? Any suggestion where I can find documentation of how to do something like this? Maybe this is not the right place to ask about it, but hey! it's about my experience with the AG-5 ;-)


I've read a bit about how Xmodmaps and Xkb work, but haven't found anything that works for me yet…

Foreign characters in Linux – answer

From: Lars Krueger Date: Fri, Jun 30 2006 1:38 pm

> and tried the second Didger's post without luck. Appart from changing

> "/usr/share/X11/xkb/symbols/us" or "/usr/share/X11/xkb/symbols/es" - in

> my case, and restarting the X server, is there somthing else I must do?


Depends a bit on your distro. Mine is a SuSE 8.0 (yes, that old :-) ) with Xfree86 4.2.0. If you want to change the keyboard layout (e.g. us -> es) there are some ways to do it.


  1. Select it from KDE's control centre or whatever GNOME uses.
  2. KDE has a tray icon for multiple layout, much like windows has. I guess GNOME has something like that too, but I have no idea what the name is.
  3. Edit /etc/X11/XF86Config. Do this for other window managers (FVWM, Ion, WMII, ...). Locate the section "InputDevice", driver "keyboard". Change

Option "XKbLayout" "us" to Option "XKbLayout" "es" and your done. Keep in mind that this is permanent until you hack the file again. KDE allows you to switch.


> What I would really want is to modify the default US layout and include

> there the vowels with accent (áÁéÉíÍóÓúÚàÀèÈìÌòÒùÙ)

> and ñÑ (perhaps çÇ too - I'd like to learn french :-)).


That might be a bit ambitious. For a regular keyboard, all you have to do is to add a line like keysym period = period greater and shift-. becomes > or keycode 0x18 = q Q acircumflex Acircumflex and Alt-Gr (or Right-Alt on US-keyboards) becomes an a with a hat.


This, however, is rather tricky on the AlphaGrip because of the way X and the 'grip work:

A 'grip emits keyboard press and release events for many keys, but not for the green and red shifts. Those are handled internally and are not seen by the computer. Thats why it works without a driver on Mac, Linux, and Windows. X11 itself can only map keyboard symbols (F5 is a symbol, just like period) or keycodes (0x18, the code of the letter Q key) to other key symbols. This is just a plain table look-up, you can't do anything fancy like AutoHotkey with it.


The problem is you can only replace all, or some, keysyms with other keysyms. Unless you're willing to give up the letter e, you're pretty much stuck with US layout.


> I've read a bit about how Xmodmaps and Xkb work, but haven't found

> anything that works for me yet.


So far, I identified three ways to do something like AutoHotkey on linux:

  1. Write a kernel driver that intercepts the events and USB device level and generate fake events. Pro: works on console. Con: Requires kernel 2.6 at least, no scripting.
  2. Write an X11 driver. Pro: Scripting possible. Con: X11 only. System wide. No idea how complicated this is.
  3. Do it by intercepting core events (XRecord) and faking (XTest) key presses. Pro: Per user and scripting possible. Con: Haven't time to try XRecord yet, sync'ing between xrecord and regular events seems tricky.


My idea is to capture core events (a.k.a. key press and release) using xrecord, save their timestamp and faking the events using xtest. At the same time events are captured and remove if the timestamp is known. I have the hunch that the above does not really work, as you can't put do this without having only your driver getting events.


It is very likely that the kernel driver is the only way to go.

Need programmable device

From: ivanwfr Date: Sat, Apr 29 2006 12:54 pm

> 1. be as similar as possible for all languages


This is not good enough... Compromise is not the only way to go; with some smart approach everyone could get an adapted configuration...


Customization, Layout and printed symbols:

We definitely need a programmable device! With its keys out of sight, AG users can't hunt and peck anymore. This means that the default printed symbols are much less of a problem than with other keyboards. All this make the AG concept the prefect candidate for new layout experimentation. Anyone with good customizing software could have his own perfect layout uploaded into a firmware flash memory!


This does not mean that everyone is to devise an original layout! That should be done seriously, quite like you are dealing with right now...


What scares me about this is that you can't change your mind about a layout that will suck much of your time to learn! This is why I am not currently playing with AutoHotkey. Even if Mike's layout is not the best for me, I need to know that I am working on steady ground. Yet, I am ready to relearn the AG6 layout if Mike make it happen, hopefully with the help of studies like yours and the many comments they cause like mine... A programmable AG6, please!

Quitting QWERTY and Dvorak

From: ivanwfr Date: Sat, Apr 29 2006 3:21 pm

… This is one of the many challenges that go with ergonomic design; the past is there to make every decision difficult. It is easy to get trapped by one of the many reasons why things should not change:

  • Is it all about not being afraid of having to relearn typing from scratch?
  • Not loosing those many years of practice?
  • Would it help making the learning curve less painful if the new looked as much like the old as possible?

These all are illusions... Being honest, we all know that it will be painful!


I fail to see how QWERTY or Dvorak could take place in devising on an effective layout for this new device. Sure, each finger is acquainted to its set of letters on a standard keyboard but I am not sure that it is a good idea to build everything on that.


I rather believe it is time to turn the page once and for all, to get rid of QWERTY and Dvorak ... Their originating premises are very poor considering modern ways and means of studying ergonomic matters like this.


I can't agree more because I really don't see how we can take advantage from the experience of typing on a standard keyboard when using the AlphaGrip. It is just impossible to be more wrong than QWERTY. Building anything related to Dvorak layout would only be a compromise.


Yet, I would certainly like having one of these standard layouts wrapped around the AG as Lee sees it here: http://groups.google.com/group/AlphaGrip/msg/653e93a8f46cf40e

Response to Analysis

From: Didgers Date: Sat, Apr 29 2006 2:06 am

  1. I looked at the various language specific Dvorak layouts, and most looked like the American original. You could start by getting a hybrid out of them. The philosophy of Dvorak Layout is to reduce the effort required on a traditional keyboard. They may not have been thoroughly optimized for their language, but I'll bet it's better than what was derived from qwerty. Anyhow, there's only so many keys on the AG-5, but there are so many international characters. It would be difficult to get them all on there, and still retain a level of ease of use. AutoHotkey can only do so much.

  2. Since different languages use different letters, some letters' rarity will vary. Assuming you can even get all of the characters on the AG-5, there would be at least one language that will have a steady stream of front pecks. Probably ought to just settle for a layout that's good for two or three different languages or good for a family (Germanic, Romantic, Cyrillic, etc)

  3. My only mistakes are missed / wrong keys. I don't really have too much trouble with permutations, but that might just be me. I honestly believe that Dvorak's alternating hands rthym helps against permutation error. However, I don't have to do much international typing (occasionally some French, which is just some accents), so maybe that's an issue with typing in other languages. All I do is just use standard keyboard symbols before/after letters and then just use search and replace to polish it up (e\: => ë, i\^ => î).

  4. If you want to type with one hand, you could try to base your AG-5's layout on one of Dvorak's one handed typing layouts. Whatever layout, you will be overwhelming the physical limits, which are already being pushed due to all the international characters you're trying to type.

    The AG-5 makes typing a lot less stressful, but it's not really much of a speed thing. If you don't have time to stop and take a break for whatever, you don't have time to learn the enhanced qwerty layout, let alone some complex one you come up with.

  5. Certain Shift / Lock keys are hard coded in the AG-5. With AutoHotkey, you can work with them to get what you want.

Conclusion) There's a million possibilities, ranging from a few letter swaps to chording everything to the point of having an 8 finger chord to produce a specific byte. Use chords of 5 to produce 31 different characters if you insist on one hand. More or less, you should just decide what you want for what you do. AG-5 layout based on American Dvorak works great for me, especially since the learning curve is easier (less keys moved around). However perfect it is for a Dvorak fanboy, some would prefer to trudge through something else.

Taking Comfort into Account

From: Toby Dickenson Date: Sun, Apr 30 2006 4:34 am

On Saturday 29 Apr 2006 00:36, Matthias Schult wrote:


> The goal

> of course is to create key layouts for the AG to use in other languages.


You I make any comment on design method...... I have been planning a similar exercise using this as a starting point:



> {permutation errors} always (100%) occur when switching hands, never

> when both letters are on the same hand! That’s why Dvorak turns out

> to be a very bad idea – it maximizes typing errors. A user-friendly

> layout would try to minimize hand-switches.


I am a keen dvorak user. I agree that the hand-alternation characteristic has some effect on error rate. Certainly permutation errors make up a higher proportion of my typing errors under dvorak (although it is not obvious that the overall rate is higher).


However alternation does have a major effect on comfort, and for me that is a more important factor than error rate. For example, the word “monopoly” is all right handed on qwerty. I think typing would be less comfortable if too many words were like that.


Neither would it be good with alternation every letter. Dvorak places several common digraphs (such as ‘th’) on adjacent keys under the same hand. Typing “pith” (left-left-right-right) is more comfortable than “late” (right-left-right-left)


It would be nice to have a quantitative method for estimating these various factors (comfort, error rate, are there others?) for a specific layout.

Comments (0)

You don't have permission to comment on this page.