anelok: charset and font

Werner Almesberger werner at
Thu Sep 19 23:37:57 EDT 2013

EdorFaus wrote:
> Is there any reason *not* to use UTF-8, and only UTF-8, on the device?

I don't see any. For prototyping, I'd just stick with ASCII and
worry about the multilingual details later.

> 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,

Yeah. We can use a nice big fast PC for that :)

> 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,

I was beginning to write "Don't forget the memory card", but
then I saw below that you didn't :)

> but the MCU selection email suggests this is at most 256kB).

It's even less. 256 kB is what the series is designed for, but
the largest parts they've made so far have "only" 128 kB.

> 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.

I'm not sure what size the cards with the lowest per unit cost
have, but I would guess they're in the >= 1 GB range. That's
plenty of room for bitmap fonts.

Unicode has less than 128 k characters. Even if we assume we have
a 32 x 32 pixel font, that's only 128 bytes per glyph, less than
16 MB for the entire Unicode.

Having said that, I'd start with everything (just ASCII) in the
MCU. It'll need some "emergency" character set for maintanance
and diagnostics anyway.

> 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?

That would depend on the collating sequence of the respective
alphabet. Some alphabets may also have special composition
rules, similar to the  [Compose] [e] [']  ->  é  approach.
But I wouldn't worry too much about this for now. We should start
with the systems we're familiar with and leave defining good
methods for entering the (to us) exotic ones to people familiar
with them.

> 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.

Memory card space is very very cheap :) In fact, you have to pay
extra if you really want to get less ...

- Werner

More information about the discussion mailing list