Multi-font support

Introduction

Rockbox currently only supports one user-loaded font at a time. There has long been a desire to extend this (if only to allow different fonts on the main and remote LCDs) to allow multiple fonts to be loaded and used simultaneously.

There has been a lot of discussion (FS #4733 and FS #8385) about how the API and user-configurability related to multi-fonts should work and this page is intended to be a place for documentation of the different proposals and discussion.

Please add your proposed solutions here, as well as contributing to the advantages and disadvantages sections for each proposal.

Proposed solutions

Solution 1

The main .cfg file contains a single fonts: line listing the fonts to be loaded, and other places in Rockbox will refer to these fonts by number (the position of the font in this list). Font #0 will be the built-in system font, and fonts 1..n will be the fonts specified in this list.

e.g. the .cfg file would contain a line of the form:

fonts: helvR10,helvR12,helvR14,ter-20n

and a viewports definition in the WPS would look like:

%V|0|0|100|100|3|ff0000|00ff00|

Similarly, viewport definitions (or maybe simply font definitions) for other UI elements (e.g. menus) would also just refer to fonts in the global list.

Advantages

• It exposes the internal representation of fonts (a numeric font ID) directly to the user - which simplifies the implementation.
• The set of fonts that need to be managed by the fonts code is specified together in a single line in the .cfg file - Rockbox doesn't have to deal with any complication of fonts being specified in multiple places;

Disadvantages

• Viewport structs are less readable - the wps author has to refer to another file to see what numbers to use with which fonts.
• Removal of a font near the start of the list would mean all font numbers would change, meaning it's harder to maintain.

Solution 2

Same as solution 1 except fonts are given labels.

e.g. in the config file: "fonts: list=helvR10, wps1=helvR12, wps2=term-12" and then in the viewport line in its config "|...|list|...|" The font labels could then be used everywhere without specifing the actual font name (so if you want to change the list font everywhere you only need to change it once).

Advantages

• The font order is arbitrary and numbers dont need to be remembered;
• Having a label instead of a number in the wps makes it easier to understand.

Disadvantages

• Unless all theme authors use the same labels there is no point because every theme will need modification to work with your existing setup/

Solution 3

Have the fonts for the wps defined in the actual .wps file. Like

%Font1|[font_path]helvR10
%Font2|[font_path]helvR12

The fonts could also be defined like in solution 1 (but in the .wps file of course)

%Fonts|helvR10,helvR12,...

The viewport would be initialized like this:

%V|..|..|..|..|[%]Font1|..|..|

or

%V|..|..|..|..|1|..|..|

in the case of my second idea.

Again, the main purpose of this solution is to have the font definitions in the .wps instead of in the global config.

Other fonts like recording or general UI font to be defined in the config. DaveChapman - How? Also, are Font1, Font2 etc hard-coded labels? Why not just use numbers/letters (similar to bitmaps) - that would make it simpler to parse. ThomasMartitz - It was just an example, feel free do it in a similar way to bitmaps. That's exactly the point of my idea, to make it as similar is defining images. Of course the simpler to parse the better. Just wanted to make sure everyone gets the example.

Advantages

• For me, it's more logical to have the fonts which are used in the wps in the corresponding .wps file.

Disadvantages

• Fonts would probably defined more than once.
• Fonts are planned to used not only in the wps, but also in menues and other contexts, so a global definition might be better.

Solution 4

Add yours