Chapter 1

.mbms can be built into ROM in a format corresponding to bitmap layout of the Symbian OS
device's normal screen mode – this makes blitting from them particularly efficient. Bitmaps
delivered with non-ROM components can be built into a compressed
.mbm file from which bitmaps are loaded into the FBS's shared heap as needed, before
being blitted elsewhere. Offscreen bitmaps may be allocated by applications: they reside in
the FBS's shared heap.
15.2.2 More on Fonts
Symbian OS can use both bitmap fonts, for which character bitmaps at various sizes are
stored and scalable fonts, for which algorithms to draw characters are stored. Bitmap fonts
are stored in a preset range of sizes; for other sizes they can be algorithmically scaled, but
the quality is unlikely to be good. Scalable fonts, however, as the name implies, can produce
any size to be produced with equal quality.
For Western locales, scalable fonts are clearly useful, but for Far Eastern they are the
difference between night and day, since the font information for even a single point size is
enormous. By using scalable font technology, information is only needed for one size. Other
sizes and rasterization for printers, can be handled by the scalable font system.
A number of systems for scalable fonts have been invented, well- known instances being
Apple's TrueType, and the open-source FreeType. Symbian OS has a framework called the
Open Font System, that allows rasterizer plug-ins DLLs to be supplied that support particular
systems. Such a plug-in recognizes and reads font files stored in a particular format, and
generates character bitmaps, which are then handled exactly as bitmap fonts.
However, scalable fonts are not always required. For example, the P800 uses only a small
and fixed number of bitmap fonts. This is because it has no application requirement for a
large set of fonts, such as a word processor. All applications will generally know which
font/size they require for any specific widget. As such fonts 'could be' requested by UID
rather than a device-independent TFontSpec specification. This is an optimization issue.
If using TFontSpecs, whether a font originated as a bitmap, or from a scalable font
rasterizer, is transparent to clients. The same method that we have already seen is always
used:
� You use a TFontSpec (and its supporting classes) to specify a font in a deviceindependent
way.
� You use an MGraphicsDeviceMap, which ultimately leads to a CGraphicsDevice,
to get a device-dependent font, using GetN-earestFontInTwips() and the
TFontSpec.
You can find out what fonts are available on a device through its typeface store,
implemented by CTypefaceStore. You can ask how many typefaces there are, iterate
through them all, and get their properties. The FontsShell example in the SDK
(\examples\graphics\ fonts\FontsShell.mmp) does exactly this.
Fonts for the screen (and offscreen bitmaps) are managed by the font and bitmap server
(FBS). When you allocate a font, using GetNearestFont...() or similar functions, it
creates a small client-side CFont* for the device, and also ensures that the bitmaps for the
font are available for blitting to the screen (or offscreen bitmap). For built-in bitmap fonts, the
font bitmaps can be in ROM, in which case the CFont* acts as a handle to the memory
address. Getting a font is a low-cost operation for such fonts. Alternatively, fonts that are
installed or generated are loaded into RAM and made accessible so that all programs can