From: Greg Haerr <greg_at_censoft.com>
Date: Tue, 10 Sep 2002 21:07:49 -0600

Daniel & Bjorn:

: Hey, it is time to get the loadable fonts into the code and used for real.
: I know several people have played with it and I've just had a session of it
: myself. In general this is very cool stuff. Loading your own font is major
: coolness.

OK - I've finally got around to designing and implementing a
complete font solution for Rockbox. I'm ready to submit a patch
that implements both compiled-in fonts and loadable fonts, using
the same internal structure, and allowing any BDF font to be converted
for use with Rockbox on devices with bitmap screens. There are
still issues, however, and I thought I'd mention them on the list first
before submitting the whole thing.

These are solely my comments after having taken a deep look at
the current font implementation and designed a new one.

Current design comments:
1. The current source is basically a mess. There are zillions of
#ifdefs for in core fonts, proportional fonts, and loadable fonts,
and none are compatible. There are no structures, everything's
a char *. Usage and definitions of the lcd_xxx API differs
depending on what's defined, and, worse, non-lcd API's have
crept into the applications code (ajf_xxx).

I can submit a patch that sorts all this out, but it may have ramifications
to the immediate useability of the CVS tree until folks who wrote original
applications code make some changes that will be necessary. For instance,
when any font is allowed, the font height won't always be 8, and there's
tons of #ifdefs for this crap already. I then need to merge the
whole LCD_PROPFONTS, LOADABLE_FONTS, and LCD_CHARCELLS
madness.

New design comments:
1. The firmware layer of the new implementation allows any
combination of compiled-in and loadable fonts to be brought into
rockbox applications and system software. Any font can be automatically
proportional or fixed, compiled-in or loaded, unicode or not.
The application shouldn't have to know all of this in detail. All
text output routines will require a font number to be used, which associates
a lower-level font data structure for the lcd_xxx drawing routines.
My proposal is to start with three #defined fonts that applications
can use:

#define FONT_SYSFIXED 0 - this font is a fixed-width font
that is small, len 0x20-0x7e that is compiled into rockbox. It
is not normally used, but is around if other font loads fail.
(All of this is set in firmware/fonts.c, and can be tweaked by programmer)

#define FONT_UI 1 - this font is a proportional font that is used
for the menu routines and rockbox system functions. It is loaded
from disk at startup as "systemui.rbf" (.rbf is the new rockbox
file format documented in firmware/font.h)

#define FONT_MP3 2 - this font is used to display disk filenames
and MP3 tag data. It is loaded from disk at startup, and used
to display special MP3 filenames, if desired.

When the applications code specifies a font to use for display,
the system tries that font. If the font was not loaded/compiled-in
at startup, the ID is decremented, and tried again, until ID 0.
This allows the entire system to be coded for multiple fonts, but
can actually run on the system fixed font if desired.

2. I've designed a program to convert any BDF file to
either a .c file or a loadable font file. When a loadable font
is loaded, it's internal structure is exactly like that of a compiled-in
font. This saves a lot of code and makes the system design nice.

3. Currently, the entire patch is coded under LCD_PROPFONTS,
which allows the older original font to run for the time being, as well
as the AJF loadable fonts. But what we _really_ need to do is
move to a single new font format.

4. My patch is currently against 1.3, rather than CVS. This may mean
problems, I wasn't able to get the CVS source. What is the best
way we should go about all of this?


:
: However, the code have several non-serious weaknesses I'd like to see
: corrected:
:
: 1. The .ajf file format is totally undocumented. We can't have that.

FIXED. Also, I recommend we move to a .fnt extension,
it will be more intuitive for users, and people can pass fonts
around and know they're fonts.

:
: 2. The functions don't have any comments explaining what they do, why
: following the flow is troublesome, especially in combination with 1.

FIXED

:
: 3. The code doesn't use the single-letter width field that seems to be stored
: in the file, and loaded, but somehow lost. Thus, proportional fonts end
: up monospaced on screen. Quite a loss.

Rewritten. The new design uses a variable width array per character
only when the font is proportional. There's only a single draw routine,
unlike the 4 or 5 we've got now. firmware/drivers/lcd.c needs some
serious cleaning up. I can submit a patch for all of this, if desired.

Also, I don't yet have full unicode working, since the applications
themselves don't use unicode. The font routines are ready, though.


:
: I'm really looking forward to getting loadable fonts in my box.

Let me know how I should proceed with my patch, and how
we will keep everything together during the conversion period.
Basically, what I'm trying to say is that I can submit a patch that
seriously solves all major issues, but there will be a period when
all applications functionality needs to be tested.

Regards,

Greg




:
: --
: Daniel "Bagder" Stenberg -- http://rockbox.haxx.se/
:
Received on 2002-09-11