: We use a fixed size static memory area for loaded fonts. That's the cache.
: can load N fonts into the cache and thus we can use at most N different
: simultaneously on a single screen.
: N can differ depending on the actual target model, just depending on how
: memory we want to provide/waste for fonts.
: If an application selects to display a font that isn't in the cache
: it loads that font (and possibly flushes an old one from it).
: Thus, we can support displaying of numerous fonts, while we only support N
: simultaneous ones. In most screens you only use a single font anyway. The
: downside is that the selecting of a font that isn't in the cache requires
: disk spin-up and load.
For N = 2, things are simple. For N > 2, the biggest issue will
be the complexity of the memory management desired. The font
files aren't quite in read-only format, so it takes time to load a font,
other than just reading disk. (this could be lessened by moving to
a read-only font file format w/pre-rotation, although table offsets
still have to be calced). The easiest implementation essentially
discards a font and re-uses the same "open" code to (re)load
a font that's required, rather than using special additional code
to reload a font. In this way, only the mem location to put
the font is problematic.
: I would imagine that we could have the font changing function have a
: that asks for the specified font mandatory or optionally, and in the
: case we could have a fancy way for the font subsystem to pick the one of
: already loaded fonts that is most similar to the one you ask for.
The system always tries to get the font, otherwise, it downgrades
and returns a default font instead. We probably don't need the
mandatory or optional functionality. My take would be that
the config file format would completely specify an application
font use with a font filename. Then, when the application requests
its font, the config mapping is always used unless the font file is
missing, in which case the default font number is returned.
In this way the application doesn't have to go through "open"
routines with fonts, it just uses application-specific FONT_xxx
values, which the config file parser knows about (and has already
parsed). The application would "request" a font for drawing,
which would return a system font id from the passed application
font id, useful just for the duration of the application drawing
(but cached by the lower level).
Received on Thu Aug 25 19:37:37 2005