release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Wiki > Main > MultiFontSupport (compare)

Difference: MultiFontSupport (r7 vs. r6)

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 viewport would be initialized like this: %V|..|..|..|..|[%]Font1|..|..|

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 acutally in the corresponding .wps file.

Disadvantages

Solution 4

Add yours

r9 - 22 Mar 2008 - 15:59:03 - ThomasMartitz

Revision r7 - 17 Mar 2008 - 02:01 - ThomasMartitz
Revision r6 - 16 Mar 2008 - 22:57 - DaveChapman
Copyright by the contributing authors.