From: "James Governor" <jgovernor@illuminata.com>
> Just wondering about michael's idea on predictive entry.
Just after I've weighed in *against* predictive entry?
> ...Where would the
> dictionary be held for the lookups? The client? Gateway? At the back
> end? Are we already confident enough of the memory size of keitai that
> such questions are not an issue? Asics or eproms perhaps?
I've been talking about input using abbreviations, so Yes, there is
the problem of where to put the lookup table.
But this is a problem with kanji henkan as well, and Japanese
gadget designers seemed to have solved it. I'd say they've solved
a harder problem, if anything. (Oh boy that is gonna start an
argument I know.) Even if you just decided you're only going
to do the 5,000 most frequent Japanese words for a kanji
henkan keitai input system, you're talking at least 50K bytes of
ROM, I'd think, just for table space. A drop in the bucket,
these days. If mapping the top 98% of English took 70K, it
wouldn't be a strain.
[snip]
> How does it work with henkan?
Why would it have to? If you used c-print, you'd be in an English-
speaking market anyway.
Or do you mean "how would you adapt this idea to kanji henkan?",
well, it's basically henkan anyway. Just for English. Define "henkan"
as "an input system that maps one set of character strings onto
another" which is about all kanji henkan comes down to anyway.
> This solution just sounds a bit hairball to me. You can imagine
> engineers in Redmond designing a multitude of such systems for PocketPC
> 2002
Microsoft? "Hairballs-R-Us"? They do hairballs in their sleep.
Anyway, this isn't a hairball. This is little more than table lookup.
-michael turner
leap@gol.com
Received on Fri Dec 21 15:06:20 2001