anelok: charset and font

EdorFaus edorfaus at xepher.net
Sun Sep 22 17:47:10 EDT 2013


On 09/20/2013 05:37 AM, Werner Almesberger wrote:
> 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.

Yeah, that works (UTF-8 is a superset of ASCII anyway).

For a prototype we probably don't have to worry too much about it, like 
you say, but should probably still keep it in mind when moving past the 
prototype stage, so we avoid making design choices that make 
internationalization harder unnecessarily.


>> 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 :)

Well, sure. Just another entry in the Makefile... :)


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

Yeah; I figured we might not go for the largest one (and you say the 
largest ones mentioned aren't even in production), hence the "at most".

I basically meant it as an upper limit estimate, to compare with an 
estimate of the font size, which I expected (and you confirmed below) is 
likely far larger if we were to include everything.

Which means that we simply *can't* have a full and complete font in the 
on-board firmware, so we have to either support only a subset of 
characters, or keep (most of) the font elsewhere (which in practice 
means on the SD card).


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

This is basically what I meant as well - that we'd keep the basic core 
set of characters (those needed to show the UI etc) in the on-board 
firmware image, so that anelok can still function even with a completely 
blank (or missing/faulty) SD card.

Then, in addition to that, since the SD card would easily hold a 
complete font, the firmware could support loading the remaining 
characters from there when they're needed, if such a font file is 
present, so that users who need to see more characters can add one.

It's not needed for the prototype stage, though, and is (AFAIK) a pure 
software issue, so implementing it should be left for a later stage.


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

Well, yes - but I'm thinking about the on-board memory space here.

In short, I feel that the device should still be functional with a newly 
bought, completely unused SD card.

If the firmware requires certain files to be present on the SD card, 
then it also requires a trusted PC with which to add those files, and 
means the user has to perform some extra steps to make their device 
operational.

We could of course support keeping additional locales on the SD card, 
that the user could then optionally select from.

Similarly, if we run into space problems, it should be possible to keep 
certain extra features (past the basic set) on the SD card instead (kind 
of like installing apps I guess), as long as the device still functions 
(for its primary use of managing passwords) without them.

Not sure what features that would be, really, but I guess an example 
could be something like password strength checking that uses a database 
of words that shouldn't be used (because crackers use the same list), 
and the database (or maybe some heuristics code or something) is too 
large for the internal memory.

Like the extended font, though, these things are not necessary for the 
prototype stage. (I'm mostly just mentioning things as they occur to me, 
so that we don't miss them later when it's time to deal with them.)

-Frode



More information about the discussion mailing list


interactive