I've been thinking about the text we need to display on the device.
I assume we would like to support passwords/phrases in whatever language
the user uses, even when that requires non-US-ASCII characters, and that
we might even want to support localizing the UI.
Is there any reason *not* to use UTF-8, and only UTF-8, on the device?
I don't think it would be a good idea to restart the whole codepage mess
from the old days, and Unicode is the only real alternative, and UTF-8
is the most common (and most compact AFAIK) encoding of Unicode.
There's also the question of what font, or at least font type, to use.
I assume the simplest to implement would be a basic bitmap font, but
then we'd probably have to convert some other font to that format, and I
worry that the font file might get too big for the device (depends on
how much internal storage is available for the firmware, but the MCU
selection email suggests this is at most 256kB).
The alternative is implementing a vector font renderer (TrueType etc.),
which I assume is rather more complex than a bitmap font renderer,
especially if we want it to look good at small sizes. (FreeType[2] might
be useful for this? Not sure, it seems to be mostly about handling the
font file formats, but I may be wrong about that...)
[2]: http://www.freetype.org/freetype2/
In either case, we might be able to reduce the size of the font file (if
necessary) by limiting the supported characters to either the most
common, or to those we can find in existing keymaps (for auto-typing),
as those are the most likely to be used.
I suppose one option could be to have just a small basic font in the
firmware, but support keeping a larger, more complete, font on the
memory card for those who want/need to display more characters.
Now that I think about it, there's another issue with this, related to
the suggested input method: which characters, in what order, should be
included in the list of characters that the user can scroll through?
I assume the formulas Werner came up with in the user interface email
could be useful for figuring that out, but I'm not really sure how to
use them.
It's probably best to keep the character list separate from the code, as
an i18n item, as what's appropriate probably depends on the locale. E.g.
Japanese users would probably prefer kana over latin characters.
Hm, just from a practical point of view, we'll probably need to make
l10n be compile-time (for the firmware) instead of user-selectable on
the device itself. Otherwise, we'd end up having to store all the
various languages and lists and stuff on the device, despite most of
them never being used, just taking up precious space.
-Frode
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
