A method from pocket pc
I've tried using this: http://www.spbsoftwarehouse.com/products/fsk/screenshots.html
It works quite well. EsbenDamgaard 15:17, 21 March 2007 (CET)
A method from Agenda VR3
The Agenda VR3 was a linux-based PDA, also with no keyboard. Their solution was to provide an onscreen keyboard, but in addition to the A/a/1 buttons to have a button that opened up a pad for handwriting recognition. Early versions used something called 'scribble' but later versions used XMerlin. So that might be an interesting idea.
What about to use fonts for the Input metod? is it hard? I think that the widget-keyboard could be dynamic. Connect the input with the orphographic vocabulary, so 5 most probable letters will have bigger area( enough for the finger) (fonts are scalable sometimes) As a transparent widget was shown,the bigger-letters can be on the background of the whole keyboard - each letter on its place. And you can find a little place for the button with the most probable word (may be form with variants).
Maybe a landscape QWERTY-Keyboard with one preview text-line would be the best to input text. - maybe later as a transparent version without the textline...
KlaymenDK says: I don't want to mess things up, so I keep to the Talk page. Here's my issue: This page seems to be the only one even mentioning handwriting. The article page states that the Input Method Widget supports "both handwriting recognition, and keyboards", yet the rest of the article seems to not discuss handwriting at all.
I propose creating a section called "Handwriting" to contain this topic.
Being a happy user of a Palm T3 with TealScript, I am quite fond of using the stylus for text input, especially in the "write everywhere" mode where one can use the entire screen as an input area.
I believe that handwriting is worthy of consideration because:
- IMVHO, it is the most efficient method for fast input on small devices.
- It is agnostic of keyboard layouts and special language variants (I use Norwegian Dvorak).
- It consumes no screen real estate at all!
- It does not preclude the use of an ad-hoc on-screen keyboard.
As I see it, there are two main issues:
- Are there any legal blocks to using handwriting recognition?
It does not seem so; at least, several open source recognition toolkits exist (LipiTK, HRE, CellWriter, others).
My main concern is if single-stroke characters are covered by Graffiti patents, and if TealPoint Software (TealScript) holds any patents on user-configurable strokes.
- Is the OpenMoko actually capable of supporting online handwriting recognition?
Here I mean in terms of processing power and real-time stroke resolution. This is a technical aspect I have no way of answering.
Another issue could be how to actually integrate the handwriting mode into the user interface. I think that the way it works on Palm/TealScript is quite nice, if not outright ideal. Basically, the way it works is: a tap is regarded as a tap if it's quick or if it's obviously a tap-and-hold. But a tap with a "running start" is regarded as a stroke and interpreted as a character, which is then sent to the application (that is, field input or command character).