Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (Symbian Books), страница 99

Off-screen bitmaps may be allocated by applications: they residein the FBS’s shared heap.More on fontsSymbian OS can use bitmap fonts, for which character bitmaps at varioussizes are stored, and scalable fonts, for which algorithms to draw characters are stored. Bitmap fonts are stored in a preset range of sizes: forother sizes they can be algorithmically scaled, but the quality is unlikelyto be good. Scalable fonts, however, as the name implies, can produceany size with equal quality.For applications using Western character sets, scalable fonts are useful;for Far Eastern character sets, they are vital, since the font informationfor even a single size is enormous. By using scalable font technology,information is only needed for one size. Other sizes, and rasterization forprinters, can be handled by the scalable font system.A number of systems for scalable fonts have been invented, such asApple’s TrueType and the open-source FreeType.

Symbian OS has aframework called the Open Font System, that allows rasterizer plug-inDLLs to support particular systems. Such a plug-in reads font files and generates character bitmaps, which are then handled exactly as bitmap fonts.Scalable fonts are not always required. For example, the P800 uses onlya small and fixed number of bitmap fonts because it has no applicationrequirement, such as a word processor, for a large set of fonts. All applications generally know which font and size they require for any specificwidget. These fonts could be requested by UID rather than by a deviceindependent TFontSpec specification. This is an optimization issue.If using TFontSpec, clients cannot tell whether a font originated asa bitmap or from a scalable font rasterizer.

The method that we havealready seen is always used:• a TFontSpec (and its supporting classes) specify a font in a deviceindependent way• an MGraphicsDeviceMap, which leads to a CGraphicsDevice,gets a device-dependent font, using GetNearestFontInTwips()and the TFontSpec.You can find out what fonts are available on a device through itstypeface store, implemented by CTypefaceStore.

You can ask howmany typefaces there are, iterate through them, and get their properties.The FontsShell example in the UIQ SDK does exactly this.550GRAPHICS FOR DISPLAYFonts for the screen (and off-screen bitmaps) are managed by the fontand bitmap server (FBS). When you allocate a font, using GetNearestFont() or similar functions, it creates a small client-side CFont* objectfor the device and ensures that the bitmaps for the font are available forblitting to the screen (or off-screen bitmap).

For built-in bitmap fonts, thebitmaps can be in ROM, in which case the CFont* acts as a handle tothe memory address. Getting a font is a low-cost operation for such fonts.Alternatively, fonts that are installed or generated are loaded into RAMand made accessible so that all programs can blit them efficiently from ashared 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 ofan installable font, decrements a usage count that causes the font to bereleased when the usage count reaches zero. Installable fonts are a mainreason why a GetNearestFont() call may fail (because of a potentialout-of-memory error).

It is worth releasing a font as soon as possible tofree up the memory.Sometimes, you want a device-dependent font. For instance, you maywant a font of a particular pixel size, without going through the troubleof mapping from pixels to twips and then back to pixels again. For this,you can use GetNearestFontInPixels() on most graphics devices:this uses a TFontSpec but interprets its iHeight in pixels rather thantwips. Or, you may want one to use a special character from a particularsymbol font.

For this, you can use GetFontById(), which requires youto specify a UID rather than a TFontSpec.An application such as a word processor may utilize a large number offonts, 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’tdevice-independent enough.

You cannot rely on any particular typefacebeing present on any device. In response, Symbian applications usuallycontain font specification information in resource files, so that this aspectof an application can be localized: there are FONT and NAMED_FONTresource structures for this.Additionally, TFontSpec can specify a font by typeface attributes.For example, most Western-locale devices have a sans serif typeface suchas Arial or SwissA.

To avoid hard-coding device-dependent names suchas these, you can simply set the proportional attribute of the typefaceand leave the others, including the name, clear. You can do this by calling TFontSpec::iTypeface.SetIsProportional(ETrue). Thenwhen you request a font of a given size, the best match for it is found.Do not over-generalize: text-layout conventions are different for FarEastern applications, so you may have to change other things if youwant to support Far Eastern locales.

You do not need to make anyspecial font-related changes to support Unicode-based Western-localemachines.DEVICE- AND SIZE-INDEPENDENT GRAPHICS551More on printingA comprehensive print model is built into the GDI and implementedby higher-level components of Symbian OS. Note however that printingis usually only relevant to larger, communicator-type phones. Morecompact devices usually find it unnecessary and cut out the support.To provide system support for particular printers, printer drivers arewritten as plug-ins that implement the CPrinterDevice interface andstored in the /system/printers directory.

On the client-side, theusual approach is to use the provided GUI dialog (if present, it is usuallycalled CEikPrinterSetupDialog) to allow the user to set up and startprinting. Print setup options can include:• page setup: paper size, margins, rich text for header and footer, pagenumbering, header on first page, footer on first page• print setup: the number of copies you want to print and the driver youwant to use• print preview: a preview showing the layout.In your document model, you should externalize the print settings.Of course, such options can also be set up directly: CPrintSetup isthe key class here. On-screen print preview support is provided throughCPrintPreviewImage.

And, as we have already seen, at the heartof any print-enabled application you have to implement the PrintBandL() function of MPrintProcessObserver.Programming printer support to this extent is not very difficult. However, if you do need to print from your application, then the requirementsto write code that is independent of a particular user interface increasehugely, to where it becomes a key consideration for many elements ofthe application.For example, an application toolbar can be highly device-dependent,as can the menu and the dialogs (though some size independence in thelatter case would be useful). On the other hand, a text view intended fora word processor should be highly device-independent.The requirements for printing text efficiently and for fast interactiveediting of potentially enormous documents are, however, substantiallydifferent.

So the Symbian OS text view component contains much sharedcode, but also a lot of quite distinct code, for these two purposes.Less-demanding applications have a greater proportion of shared code.To take another example, without considering printing, a spreadsheetcould be considered to be an abstract grid of cells, each containing text,numbers, or a formula. If you take that view, your drawing code canbe pixel-oriented and it won’t be too difficult if you decide to supportzooming.

But this changes if people need to print the spreadsheet, withsensible page breaks and embedded charts. If you write a spreadsheet552GRAPHICS FOR DISPLAYthat supports all this, you need to design for printing from the beginningand optimize your on-screen views as representations of the printed page.Color managementThe basic class for color is the TRgb: a red–green–blue color specification. A TRgb object is a 32-bit quantity, in which eight bits are eachavailable for red (R), green (G), and blue (B).

The other eight bits areoften unused; in some situations, they are used for alpha (transparency)information.Wasted memory in such a fundamental class in Symbian OS? Actually,the waste is small. First, it is hard to process 24-bit quantities efficientlyin any processor architecture. More importantly, TRgb s do not exist inlarge numbers – unlike, say, the pixels on a screen or bitmap. Bitmapsare stored using only the minimum necessary number of bits.Constants are defined for the set of 16 EGA colors.2 The followingdefinitions in gdi.h show how the R, G and B values are combined in aTRgb:#define#define#define#define#define#define#define#define#define#define#define#define#define#define#define#defineKRgbBlackKRgbDarkGrayKRgbDarkRedKRgbDarkGreenKRgbDarkYellowKRgbDarkBlueKRgbDarkMagentaKRgbDarkCyanKRgbRedKRgbGreenKRgbYellowKRgbBlueKRgbMagentaKRgbCyanKRgbGrayKRgbWhiteTRgb(0x000000)TRgb(0x555555)TRgb(0x000080)TRgb(0x008000)TRgb(0x008080)TRgb(0x800000)TRgb(0x800080)TRgb(0x808000)TRgb(0x0000ff)TRgb(0x00ff00)TRgb(0x00ffff)TRgb(0xff0000)TRgb(0xff00ff)TRgb(0xffff00)TRgb(0xaaaaaa)TRgb(0xffffff)We use #define rather than const TRgb KRgbWhite = TRgb(0xffffff) because GCC 2.7.2 didn’t support build-time initialization of class constants.