Chapter 1

lit them efficiently from a shared heap. The CFont* acts as a handle to an address in this
heap.
Releasing a font releases the client-side CFont* and in the case of an installable font,
decrements a usage count, which will cause the font to be released when the usage count
reaches zero.
Installable fonts are a main reason why GetNearestFont...() calls may fail (because of a
potential out-of-memory error). Also note that it is worth releasing them as soon as possible,
to free up the memory.
Sometimes, you want a device-dependent font. For instance, you may want a font of a
particular pixel size, without going through the trouble of mapping from pixels to twips and
then back to pixels again. For this, you can use GetNearestFontInPixels() on most
graphics devices: this uses a font spec but interprets its iHeight in pixels rather than twips.
Or, you may want one to use a special character from a particular symbol font. For this, you
can use GetFontById(), which requires you to specify a UID rather than a font spec.
A word processor-like application will potentially utilize a large number of fonts, because
there would generally be a number of fonts to select from and each would have a large
range of sizes.
Sometimes the device-independence implied by a TFontSpec isn't device-independent
enough. You can rely on Arial, Times New Roman, and Courier fonts or similar being
present on any Western-locale device but not, for example, in Far Eastern locales. In
response, Symbian applications usually contain font specification information in resource
files, so that this aspect of an application can be localized: there are FONT and NAMED_FONT
resource structures for this.
But don't overgeneralize: text layout conventions are different for Far Eastern applications
too, so you may have to change other things if you want to support Far Eastern locales. You
don't need to make any special font-related changes to support Unicode-based Western-
locale machines.
15.2.3 More on Printing
A comprehensive print model is built into the GDI and implemented by higher-level
components of Symbian OS. Note, however, that printing is usually only relevant to larger,
communicator-type phones. More compact devices usually find it unnecessary, and cut the
support.
To provide system support for particular printers, printer drivers are written as plug-ins that
implement the CPrinterDevice interface, and stored in the /system/printers
directory. On the client-side, the usual approach is to use the provided GUI dialog (if present,
it's usually called CEikPrinterSetupDialog) to allow the user to set up and start printing.
Print set up options can include:
� page setup: supports paper size, margins, rich text for header and footer, and options
for page numbering, header on first page, footer on first page;
� print setup: the number of copies you want to print, and the driver you want to use;
� print preview : a preview showing the layout.
In your document model, you should externalize print settings.
Of course, such options can also be set up directly: CPrintSetup is the key class here.
On-screen print preview support is provided through CPrintPreviewImage. And as we've