From: Greg Haerr <greg_at_censoft.com>
Date: Tue, 23 Aug 2005 17:10:55 -0600

Hi,
    I thought I'd comment on Daniel's thoughts about adding
multiple fonts to rockbox. I'd like to think of adding this
capability in two levels, a lower system level, where fonts
are loaded and actually displayed, and at an application level,
where different fonts may be requested to be displayed
by the running (Rockbox) application.

My comments follow. Of course, basic multiple font support
is easy, my original contribution had multiple font support.


: We have a font cache with named fonts (like "uwe-prop14", "chicago12" and
: "alt6x10"). The cache fits N fonts, where N must be at least the number of
: simultaneous fonts we support (which _could_ be dynamic so that we support
6
: small fonts or 2 big ones etc).

The font cache should house numbered fonts, not named fonts. Only
a system level routine should load a named font into a numbered location.
The "current font" can then be set by the application level (or added
as a parameter, if desired to the textout api call), without adding much
application complexity.

There needs to be some discussion regarding how many lower level
fonts should be loaded, since we don't have dynamic memory. Perhaps
the config option that specifies the font name and its application display
use
counts them and allocates memory for all specified. The application
would have a config option allowing for any FONT_xxx to
have a specific font used if desired.

:
: Internally, we have a long list of font ID to font name mappings. Like
:
: FONT_RADIO
: FONT_DIRBROWSE
: FONT_MENU
:
: Each of these can be set to a specific font name by the user (through a
config
: file). Of course, if a font is to be used that isn't already in the cache,
it
: will get loaded into the cache from disk (and the least recently used font
: gets discarded from the cache if the new one doesn't fit).
:
: The system built-in font has its own font name (like "default" or so)
which
: means that using that won't occupy space in the font cache at all.

I think the above FONT_xxx should just be an enum, with values
from 0. FONT_SYSTEM would be 0, with optional values
starting at 1. Rather than loading fonts on the fly, which has
memory allocation issues because of the differing bitmap sizes,
all fonts could be loaded at boot, and then when the application
requests FONT_xxx, the font is used if present, or FONT_SYSTEM
is defaulted. The current font format is designed such that
the font file can be loaded "as-is", with width table and bitmap
offsets pointed to by the font loader.

The application never knows the optional or default sizes, any
on-screen formatting must use a lower-level system call to determine
sizing information. In this way, the application specifies a "desired"
font, rather than a mandatory font.

: ... and let's assume that WPS1 is the smallest and WPS4 is the biggest.
Using
: this, a WPS designer can use 4 sizes, while a user of such a WPS can still
: elect exactly what fonts to use for those sizes.

Font aliasing could be done in the config file if necessary, otherwise
dynamic size information would be requested by the application.
I don't see the need for aliasing, if the font section of the config file
just specifies the font the user desires for that portion of the
application display.


: Italic/Bold - shall we support such styles to a given font or shall we
just
: force users to just specify a font with these characteristics instead?
These
: styles can get made on a font run-time and thus not wasting any extra
space
: for them, but is it worth the extra code?

The extra code to bold is extremely simple, providing we have a
low level routine to draw only foreground bits - erase bkgnd, draw bits,
move right one pixel, draw again. Italic doesn't always look as good,
but it'd be much cheaper in ram usage not to have to have a italic
versions of every font available just to draw italic on occasion.

Regards,

Greg

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2005-08-24