Dedicated font server for Qt on Symbian

In a nut shell

For faster, more memory efficient and more flexible font/text handling, Qt needs a dedicated font server. Right now (without that server), the font/text handling of Qt on Symbian is very suboptimal, especially before the exteded Api that was implemented for "Symbian^4".

What Qt needs to render fonts

Qt essentially needs the following things (ideally from the underlying platform) in order to render fonts:

• Access to a list of fonts which are installed on the system. The QFontDataBase gets populated with that list. The meta data like writingsystmens/scripts or bold/[italic|http://doc.qt.nokia.com/latest/qfontinfo.html#italic] needs to be read from Symbian and be reflected in the QFontDataBase. This happens at Qt application startup and needs to be fast.
• Access to Glyph metrics: The dimensions of the glyphs are needed for text layouting. The access to thaht information happens very often and needs to be fast.
• Access to the rasterized Glyphs: For the raster graphics system alpha channels of glyps; For OpenVG handles to VGImages of glyphs. Ideally, the glyphs are shared system-wide, and the access is fast.
• Access to the TTF Font tables. The main usage of the tables is Qt's shaping with the included HarfBuzz shaping engine.
• Access to Glyph outlines. Qt's Api provides access to vector outlines of text, and uses the outlines internally to render heavily transformed (or huge) text. This is not intended for rendering much text quickly.
• Possibility to load custom (TTF) fonts to be used in the application.

Current font/text implementation problems in Qt on Symbian

Font Tables (only S60-3rd/S60-5th/Symbian^1)

Qt uses the Font and Bitmap Server (FBSERV) as much as possible to get the required data. However the essential Font Tables cannot be accessed. In order to acces the Font Tables, Qt loads all fonts from the :\resources\fonts folders on the device and loads these into an own in-process CFontStore instance. That is in the first point slow. And it is memory hungry because each Qt process does that.

Glyph outlines (only S60-3rd/S60-5th/Symbian^1)

Glyph outlines are also not available before "Symbian^4". So, Qt falls back to get the rasterized glyphs and to trace them. That is slow very slow, and the resulting outline is very ugly, far away from the original glyph.

Custom Application fonts

Symbian offers an Api to load a custom font into the FBserv. There are multiple issues with that Api:

• An added font is accessible by all processes but disappears as soon as the process that added it removes it. Should only be accessible/visible for the process that added the font.
• There is no way for a process to distiguish between real system fonts and fonts that have been added by other processes.
• Only fonts files that are read-accesible by FBSERV.exe can be loaded. FBSERV.exe does have low file accessibility capabilities. So, no files from private application directories can be used.
• Fonts cannot be added as data array. Only as file. That makes direct loading of fonts that are embedded in Qt resources, or Web fonts impossible.

The FontRouter problem

FontRouter is a very nice tool filling a big functionality gap in Symbian: System font customization. However, the way how FontRouter does it, is pretty venturesome and breaks (undocumented) Symbian Font Api which is used by Qt. Therefore, Qt is incompatible with FontRouter in an apparently unsolveable way.
Also if FontRouter did not break that Api, glyphs would be garbled since Qt would read the 'cmap' font table from the system fonts and map Utf-16 to GlyphIds with that data while FontRouter uses subtitution fonts.

TBC