Slashdot Mirror
Complex Language Support for PDA's?
Jasin Natael asks: "What PDA's/Smartphones, etc. support complex languages in addition to more 'standard' languages? I'm a student of Japanese and am looking for a new PDA or smartphone that operates in English, but supports complex character sets. Input is a plus, but it's really needed for Contacts, Notes, Websites, and incoming E-Mail at a minimum. Would it be easy to add support to a Linux PDA (Zaurus) or Pocket PC for this? What about right-to-left languages, like Hebrew and Arabic?"
Zaurus must be *THE* only PDA that includes kanji input - as in, written by hand. (Okay so you can write kana into it too, so it's more like "glyph input" but I digress)
You have no idea how that saves your life (or, time - which is really just small chunks of life) when looking for the pronouciation of some kanji characters (and meanings - zaurus in Japan AFAIK comes with dictionaries either direction).
So, yeah - buy a zaurus from Japan and be amazed. I don't think the US models are so trick, buc I might be wrong.
My life in the land of the rising sun.
Display rendering is very RAM intensive. It is particularly costly for these small devices.
For a 32,000 character Japanese or Chinese font, at 14 pixels square (about the smallest readable resolution), un compressed, you are talking about 800K.
On an 8M Palm, that ends up being 1/10th of your available memory.
Hebrew, Arabic, Tamil, Devengari, or other ligatured languages have much smaller fonts, but since the character rendering changes as a result of which characters are adjavent to each other, or the start or end of the line, you have similar memory constraints for the ligature rendering software, which could be considered "part of" the font.
That's just for display, and doesn't include input.
For something like Pinjin (Chineseh input) or Kanjihand (Japanese input), you are talking additional RAM taken up to allow both "chording", and translation of the pseudo "chords" (unless you have a keyboard) into the textual representation.
Storage for data is less of a problem; but most storage uses EUC or UTF or some other multibyte encoding. If it didn't, you couldn't shove it into 8-bit "files" on a PALM; if PALM supported 16-bit "files", this would be much easier.
But since it doesn't, you don't get the average 2.5:1 information density increase you would normally get from an ideogrammatic language (average English word length is 5 8-bit characters), and it drops down to about equal density (~1.2:1), so you don't win back your memory used on input and display processing that way.
So the net result is about the same as the original Macintosh: all the RAM is taken up by system processing, leaving nothing left for data or programs.
So what this boils down to is that the support has to be built into the OS area, instead of into the user area.
About the only PALM-like device I know that can do this is the Sharp Zarus. All the other vendors tend to fill their FLASH up with, well, pieces of PalmOS, not leaving any private-use areas for language add-on vendors.
PS: Yes, I know my font size of ~800K is uncompressed; the alternative is to compress it, and then include decompression code. That sort of works, but is compute intensive enough to make the system unpleasent to use, with the underpowered processors on most PDAs.
-- Terry