Nokia N810 and 770 Internet Tablets
Input Methods

• en_GK: The Geek Keyboard
• Handwriting Training

en_GK: The Geek Keyboard

The layout of punctuation glyphs on the en_US (US English) keyboard seems to change with every version of Maemo. The one with Maemo-2.0 is very unfriendly to geeks: the punctuation most used when entering shell commands (hyphen, dollar sign, asterisk and double quote) is all shifted, and some important keys (pipe, grave accent and braces) are relegated to the symbol page. Therefore I resolved to create my own custom keyboard. My initial plan (not actually realized) was to call it English (Geek) with a locale symbol of en_GK.

The first job was to locate the keyboard configuration files: they turned up in /usr/share/keyboards. Now, what is the file's format? Reverse engineering the keyboard configuration file turned out to be harder than expected. However, I prodced this PERL script which can read and dump any of the keyboard files including latin.special.vkb, the symbol pages.

In the national language VKB files there are six keyboards: normal unshifted, normal shifted, and four pages of thumb keyboards. In each one the keys are listed by rows, in (mostly) units of 5 octets each:

1. Format variant, normally 0, or 1 for the one weird key.
2. Category code: bits indicate alphabetic, decimal, hex, accent, or two kinds of punctuation.
3. Length in octets for the following string. Usually 1, could be 0 (on empty keys) or greater than 1 (for super-ASCII Unicode).
4. The keysym as a UTF-8 (Unicode) string. (Or multiple such strings on the weird key.)
5. Key shape indicator.

I planned to change the text description, the locale codes in the file, and the filename (to en_GK.vkb), but even after a reboot the control panel applet for text input would only list the file as en_GK, refusing to show the text description, and I could not select the new keyboard. With the locale and filename as en_US but the text description changed, the applet got it right but the input method did not show any keys. With the text description reverted to English (USA), then it worked properly. Very strange. I did hack the length byte of the text description to show the actual length. I did all the work using a SSH session, so when the input method weirded out I was able to restore the saved original keyboard file.

Here is the Geek Keyboard. To use it, cd /usr/share/keyboards and rename en_US.vkb to some other name (for easy reversion). Then copy my file to become en_US.vkb. You could also use the dumper script and a hex editor (I used hexedit-0.9.7 on my laptop) to improve the keyboard file for your proper language. Hint: in the likely case that Unicode strings are changed in length, do them starting from the end of the file, so file offsets in the dump are not invalidated.

Here's a future research project: if we didn't use 1.5x wide keys at the ends of the first and third alphabetic rows, we could get two more keys onto each of two keyboards. Would the input method accept this?

Handwriting Training

This whole thing is on hold until I can figure out how to remove pattern glyphs that conflict with what I want to use, and mistakes in entering glyphs.

Several reviewers said they disliked the handwriting input method; I'm going to make my own judgment. Sphinx of black quartz judge my vow. Seven wildly panting fruit flies gazed anxiously at the juicy bouncing kumquat. OK, I got the texts to go in.

This is a partnership between you and the Artificial Intelligence, and definitely you need to have thought seriously about the technical and programming issues of handwriting recognition to be able to do your part of the teamwork. It's going to take practice to get fast and accurate, but I know that Palm users do this regularly and I'm going to keep trying. After a few days of experience I can send handwriting with an error rate and speed similar to using the keyboard. (Except, passwords are a problem because you can't be sure what's typed.) Here are a few hints:

• Read the manual section. You'll find out that as with Palm, a backward hyphen is destructive backspace (also the GUI backspace button); a forward hyphen is a space, a reverse L is carriage return, and an upper case gamma is for tab. (I would have used it for F or G.) The reverse L, at least, has to be small and well above the baseline, or it becomes an upper case J. The two hyphens have to be near or below the baseline and less than a letter width.
• As pointed out by several reviewers, the AI is anally retentive about case; keep strictly out of the riser area except for riser letters like l,k,b. There's a setting for capitalize but I think that's only for the keyboard; it uses a heuristic to hit the shift key for you, which you can unshift if unwanted.
• Alpha is for x, not a. Inverted u will do for lower case n, and rho for p.
• Lower case i and j have dots over; otherwise they're respectively l or upper case J. But the AI doesn't wait long before analysing the input, so get the dot in there fast. The delay is adjustable in Control Panel, Text Input.
• Zero requires a slash, otherwise it's upper or lower case o.
• Digit 1 needs a serif (like a 7 but very vertical). Upper case I needs serifs top and bottom; otherwise it's a lower case l.
• In symbol shift, I couldn't get a grave accent (comes out as backslash), nor a blank (comes out as underbar), nor a minus (comes out as underbar). But carriage return was recognized.
• It's not clear whether the AI can tell your stroke order, but ten question marks starting at the top were correct, whereas ten similar ones starting with the dot were exclamation points.
• It's reasonable to switch between input methods, e.g. mostly use handwriting but switch to keyboard for passwords and for editing with vi.

Decide on decent and consistent glyphs. a = alpha, b = beta, d = backward 6, f = (conventional), g = gamma (cross with loop below), q = o backslash, t = upper left corner, x = gamma upside down (cross with loop above), digit 1 = line bottom to top, I = line top to bottom.

Sorted by shape:

Cross with loop:

• left (start upper right): a (alpha),
• bottom (start upper left): g (gamma),
• right: (unused),
• top (start lower left): lower case l

Corners:

• lower right (starting at top): enter,
• upper right (starting at left): 7,
• upper left (starting at bottom): tab,
• upper left (starting at right: t
• lower left (starting at top): L

How to detect changed files:

    echo "whatever" > /tmp/timestamp.txt
    (do the activity that changes files)
    find / -xdev -type f -newer /tmp/timestamp.txt -print
    

I taught it one shape: upside down lower case gamma for lower case a. This resulted in changes to the following files:

• /var/lib/gconf/apps/osso/inputmethod/shortcuts/western/%gconf.xml --
  Contents: <entry name="-7793" type="string">
  <stringvalue>Shortcut -7792 (XML verbosity abbreviated)
  (I don't actually know if it was changed; the mtimes in the XML don't match obvious relevant file mtimes.)
• /var/lib/gconf/apps/osso/inputmethod/shortcuts/%gconf.xml --
  Mtime was changed but the file was, and is, empty.
• /var/lib/gconf/apps/osso/inputmethod/%gconf.xml --
  Mtime was changed but I don't see any content changes.
• /home/user/.osso/hildon-input-method/hwr.lib --
  Binary file, only 874 bytes compared to 814 before this lesson, no useful strings. This is probably where the user training glyphs go -- and so, reversion of mistaken glyphs would be done by backing up or restoring this file.