Font Store Component Overview

Required background

This topic requires an understanding of the font concepts and terms and the Font and Text Services Collection Architecture.

Introduction

The Font Store supports two types of fonts:

• Bitmap fonts that are stored as fixed-size pixel definitions.

• Open fonts that can be stored in any format.

Open fonts must be converted into bitmaps (rasterized) before they can be used. Therefore, the Font Store must also contain a font rasterizer for each format of open font.

Fonts are stored on Symbian devices as files. The Font Store maintains a list of font files along with specifications for each font that the file contains. When an application requests for a font, the Font Store searches its list for the best match. If the font is a bitmap font, the Font Store loads it into the FBS's shared heap (unless the font is in eXecute In Place (XIP) ROM, in which case it is accessed directly from ROM). If the font is an open font, the Font Store uses the associated open font rasterizer to rasterize glyphs into bitmaps and cache the bitmaps in the shared heap. Font rasterizers are ECOM plug-ins.

APIs

The Font Store contains APIs for specifying and selecting fonts and for rasterizing open fonts. The following diagram shows the key classes in the Font Store component. Following the diagram is a summary of the Font Store classes.

Typical uses

In most cases, FBS forwards client requests to the Font Store, which calls the corresponding APIs to handle these requests.

Loading font files

Open font files can be loaded at system startup or run time.

• At system startup, the FBS initializes the Font Store (CFontStore), which then calls font rasterizers to scan all of the drives on the device and load font files. The Font Store maintains a list of font files along with the font specifications.

• At run time, clients can call CFbsTypefaceStore::AddFile() or CFbsTypefaceStore::InstallFile() to load font files. The IPC request is sent to the FBS, which calls the Font Store and font rasterizers in turn to load the specified font files.

  Note: Font rasterizers can only be installed by restarting the phone. If loading a new font file requires a font rasterizer to read and parse the font file, the phone must be restarted.

Requesting a font

1. Clients call the CFbsTypefaceStore’s GetNearestFont function such as GetNearestFontToMaxHeightInPixels() to request a font.

   The GetNearestFont functions take the requested font specification (TFontSpec) as one of the parameters and return CFont&* on success. CFont is the pointer to the concrete instance of CFbsFont.

2. The IPC request is sent to the FBS.

3. FBS calls the Font Store’s corresponding GetNearestFont function. The function searches the font list for the best match based on the font specification.

4. If the matching font file is found in the list, the Font Store creates CBitmapFont.

5. As a wrapper, CBitmapFont constructs COpenFont, which represents the open font. In some cases a font rasterizer that implements COpenFont is called to get the requested open font.

6. CFbsFont (client-side) which declares CBitmapFont (server-side) as a data member is returned to the CFbsTypefaceStore’s GetNearestFont function.

Using a font

To use a font to render text, clients must use character data such as character metrics and bitmaps. The font rasterizer is usually called first to convert (rasterize) the character to a bitmap.

1. Clients call the CFbsFont::GetCharacterData() function and pass in the Unicode of the character to be rendered. The returning parameters include the metrics, bitmap and bitmap size of the character.

2. For performance efficiency, the CFbsFont delegates CBitmapFont to search the shared heap and system caches for the metrics and bitmap of this character. If not, the following steps are taken to rasterize the character.

3. CFbsFont sends an IPC request to the FBS.

4. The FBS sends the request to CBitmapFont.

5. The CBitmapFont calls COpenFont::Rasterize(), which is forwarded to the Rasterize() function of the derived font rasterization implementation such as the Freetype Font Rasterizer.

6. After the font rasterization, the font rasterizer returns the metrics and bitmap information to the CFbsFont::GetCharacterData() function through the FBS.

   Meanwhile, the glyph and bitmap of this character are cached in the system for later access.

Retrieving font tables and glyph outlines

Clients can call the GDI RFontTable and RGlyphOutlineIterator classes to retrieve font tables and glyph outlines. These functions are enabled only if the font rasterizer has implemented the related font extension APIs. The following explains how the request for font tables is processed by the FBS and Font Store. The request for glyph outlines is processed in a similar way.

1. Clients call RFontTable::Open(). This function takes CFont&, which points to the concrete instance of CFbsFont.

2. The FBS forwards the IPC call from CFbsFont to the Font Store's CBitmapFont.

3. CBitmapFont calls COpenFont.

4. The font rasterizer, for example FreeType Font Rasterizer performs the actual retrieval of the font table if the font rasterizer has implemented the related MOpenFontTrueTypeExtension extension.

   The Font Store caches the font table in the shared heap for later access.

5. Clients call RFontTable::TableLength() and RFontTable::TableContent() to get the table length and beginning address of the content. These two functions access the cached font table.

6. Finally, clients must call RFontTable::Close() to release resources when the returned font table is not in use.

Platform security information

Font data files are installed and saved in the folder \resource\fonts.