Font System Proposal

Overview

The current Rockbox font subsystem has limited the possibilities for expanding the UI. It is almost completely uncommented and was apparently written by a Chinese contributor that is no longer participating in development. Expanding the subsystem to support multiple fonts has been shown to be possible only in a hackish and inefficient way. In order to allow further development in this area, it is my belief that a new subsystem is required.

Porting Freetype2 to Rockbox is a way to leverage existing, stable font handling code while introducing the possiblity of new features with only a modest increase in code size. Freetype2 core (not including vector font rendering) is in part designed for embedded use and is small and highly efficient. It also includes a small bitmap glyph cache engine that appears to be perfectly suited for Rockbox. I've done some very preliminary scanning through the freetype2 code (including some initial effort at integrating it into the Rockbox source) and it seems to be a good fit.

After a very rough integration of the core, BDF and scache modules, the total lines of code added is 7,045 with an additional 4,897 SLOC in header files. It is possible that this can be cut down further (particularly the headers).

Advantages

• Ability to use BDF fonts directly, no more obscure homebrew font format.
• Arbitrary number of simultaneous fonts efficiently
• Support for greyscale glyphs (aka pre-rendered antialiasing, when users ask for 'truetype support' this is what they really want)
• On-the-fly glyph processing, ie embolden and possibly others
• Mature, documented code
• In the very distant future when our grandchildren are using DAPs with gigabytes of RAM and 16-core CPUs, potential support for real-time vector font rendering

Disadvantages

• Code size increase (probably relatively modest, on the order of a few tens of kilobytes. Existing font code can be #ifdef'd for Archos targets if it's a big concern)
• NIH

Tasks/Problems

• Freetype2 uses malloc(). It's not yet known how much core it needs, it may be possible either to emulate malloc with a static buffer (like we do with Tremor) or factor malloc() out of freetype entirely.
• Freetype2 uses ANSI C I/O. I've put together a partial and VERY hackish ANSI -> POSIX/Rockbox layer but there's probably a better way.
• Freetype2 has a fairly complex structure including portability layers that will have to be dealt with. My first instinct is to avoid altering the freetype code as much as possible to make it easier to keep in sync with upstream but it's possible that the costs of such an approach outweigh the benefits.

Discussion

Please include criticisms and ideas for improving the Rockbox font situation.