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

The rest of CExampleHelloControl is the usual kind of housekeeping that, by now, shouldhold few surprises. See the source code for the full details.PrintingCExampleHelloView is a device-independent view: it contains nodependencies on any screen device. That means it can be re-used in someinteresting contexts – especially printing. Symbian OS contains otherviews that are designed in a manner similar to CExampleHelloView.The best example of this is rich text views, delivered by the CTextViewclass.CExampleHelloView can be used for printing and print preview,where this is supported by the user interface, without any changes.

TheGDI specifies a conventional banded printing model that contains, at itsheart, an interface class with a single virtual function:class MPageRegionPrinter{public:544GRAPHICS FOR DISPLAYvirtual void PrintBandL(CGraphicsDevice* aDevice, TInt aPageNo,const TBandAttributes& aBandInPixels) = 0;};TBandAttributes is defined as:class TBandAttributes{public:TRect iRect;TBool iTextIsIgnored;TBool iGraphicsIsIgnored;TBool iFirstBandOnPage;};If you want your application to support printing, use GUI dialogsto set up a print job and start printing. You need to write a class thatimplements MPageRegionPrinter and then pass a pointer to it (anMPageRegionPrinter*) to the print job. The printer driver then callsPrintBandL() as often as necessary to do the job.The way in which a driver calls PrintBandL() depends on thecharacteristics of the printer.

Clearly, the driver calls PrintBandL() atleast once per page. Drivers may:• call PrintBandL() exactly once per page, specifying the pagenumber and, in band attributes, a rectangle covering the whole page• save memory by covering the page in more than one band• work more efficiently by treating text and graphics separately so that,for instance, all text is covered in one band, while graphics arecovered in several small bands.As the implementer of PrintBandL(), you clearly have to takeaccount of the page number, so that you print the relevant text onevery page.

Whether you take any notice of the band attributes is ratherlike whether you take any notice of the bounding rectangle passed toCCoeControl::Draw(): if you ignore these parameters, your codemay work fine but you may be able to substantially speed printing up byprinting only what’s necessary for each band.You can re-use the view code in CExampleHelloView to implementPrintBandL() for a single-page print:void CMyApplication::PrintBandL(CGraphicsDevice* aDevice,TInt /*aPageNo*/,const TBandAttributes& /*aBandInPixels*/){// Allocate the fontDEVICE- AND SIZE-INDEPENDENT GRAPHICS545TFontSpec fontSpec(_L("SwissA"), 6*10);fontSpec.iFontStyle = TFontStyle(EPostureUpright, EStrokeWeightBold,EPrintPosNormal);CFont* font;User::LeaveIfError(aDevice.GetNearestFontInTwips(font, fontSpec));// Draw the viewCGraphicsContext* gc;User::LeaveIfError(aDevice->CreateContext(gc));TRect rectInTwips(TPoint(2880, 2880), TSize(2880, 1440));TRect rect(aDevice->HorizontalTwipsToPixels(rectInTwips.iTl.iX),aDevice->VerticalTwipsToPixels(rectInTwips.iTl.iY),aDevice->HorizontalTwipsToPixels(rectInTwips.iBr.iX),aDevice->VerticalTwipsToPixels(rectInTwips.iBr.iY));iView->DrawInRect(*aDevice, *gc, rect, font);delete gc;// Release the fontaDevice.ReleaseFont(font);}Because PrintBandL() is a leaving function, we can allocate thefont within it.This code prints the text in a rectangle 2 inches by 1 inch, whosetop left corner is 2 inches down and 2 inches right from the edge ofthe paper – regardless of the paper size and margins.

More realistic printcode would take account of the paper size and margins, which are set upby the GUI dialogs.The CGraphicsDevice::CreateContext() function creates agraphics context suitable for drawing to the device; it is the way tocreate a graphics context. Calls such as CCoeControl::SystemGc()simply get a graphics context that has been created earlier by the CONEenvironment, using iScreenDevice->CreateContext().Rich text and other viewsThe CTextView rich text view class provides a powerful view thathides extremely complex functionality underneath a moderately complexAPI. This class supports formatting and display of rich text (model objectsderived from CEditableText), printing, editing, and very fast on-screenupdate – enough to allow high-speed typing in documents scores of pageslong.

User interfaces can provide controls derived from CEikEdwin, suchas UIQ’s CEikRichTextEditor, that applications can use for rich-textediting.More on the Graphics Device InterfaceDevice-independent drawing is supported by the Symbian OS GDI. Allgraphics components and all components that require a graphics object,such as text content, depend ultimately on the GDI. The GDI defines:546GRAPHICS FOR DISPLAY• basic units of measurement – pixels and twips – that are used by alldrawing code• basic definitions for color• graphics devices and graphics contexts• fonts• bitmapped graphics• device mapping and zooming• printing.The GDI is well illustrated by examples in the SDKs.

The UIQ SDK’ssample program is GraphicsShell. As its name suggests, it is a shellwith several examples inside it, including the basic drawing functionssupported by CGraphicsContext, bitmapped graphics, the CPictureclass, zooming, off-screen bitmap manipulation and the built-in fonts.We have already seen most of the GDI. In this brief section, we reviewand develop a few more themes: bitmap handling, font management,printing, color and display modes and web browsing.Blitting and bitmapsDisplays are fundamentally bitmap-oriented. Graphics primitives such asDrawLine() have to rasterize or render the line – that is, they mustdetermine which pixels should be drawn in order to create a bitmapimage that looks like the desired line.

Rasterizing in the Symbian OS isthe responsibility of the BITGDI, which implements all drawing functionsspecified by CGraphicsContext for drawing to on- and off-screenbitmaps.Another approach to updating a bitmapped display is simply to blitto it: to copy a bitmap whose format is compatible with the format onthe display. Blitting is extremely efficient if the source and destinationbitmaps are of identical format.Any GUI worth its salt takes advantage of the efficiency of blitting tooptimize certain operations:• on-screen icons are not rendered using drawing primitives but preconstructed in a paint program and blitted to screen when required• flicker-free screen re-draws are performed by rendering to an offscreen bitmap (potentially slow) and then blitting to the screenwhen needed (usually quick); the off-screen bitmap is maintainedby RBackedUpWindow; whenever a redraw is required and the window contents haven’t changed, the image can simply be blitted fromthe screen and not redrawn from scratch; redrawing is done entirelyfrom the backup bitmapDEVICE- AND SIZE-INDEPENDENT GRAPHICS547• animation is a special case of flicker-free update that can be implemented using a sequence of blits, one for each image frame• screen fonts are blitted from the font bitmaps onto the screen (oroff-screen bitmap).Blitting is a very useful technique but it isn’t always the best thing touse.

Bitmaps use a lot of memory; if you can construct a picture froma short sequence of drawing primitives, it is often more compact thanstoring the picture as a bitmap. Bitmaps cannot be scaled effectively: youlose information if you scale them down and they look chunky if youscale them up.

Scaling is generally slow, which eliminates one of themajor advantages of using bitmaps. Bitmaps are fixed: you can only usethem to store pre-drawn or pre-calculated pictures, or to cache calculatedimages for reuse over a short period of time. Bitmaps are highly efficientfor screens, but highly inefficient for printers, because they involve largedata transfers over relatively slow links.

They also involve scaling, butusually that’s acceptable on printers because the scaling is to a size similarto that which would have been used for the bitmap on screen anyway.Figure 17.17 shows a UML diagram of the classes that support bitmapsin Symbian OS.CBitmapDeviceCGraphicsDeviceCBitmapContextCFbsBitmapBitBlt()DisplayMode()SizeInPixels()SizeInTwips()CGraphicsContextDrawBitMap()Figure 17.17 Support classes for bitmapsThe class for bitmaps is CFbsBitmap, which is defined in fbs.h. Keyproperties of a bitmap include:• display mode – the number of bits per pixel and the color or grayencoding scheme (see the TDisplayMode enumeration in gdi.hand the list below)• size in pixels• size in twips• bitmap data, which you can get using GetScanLine() and similarfunctions.548GRAPHICS FOR DISPLAYNote that the CFbsBitmap constructor sets a pixel size only, but youcan also set the size in twips.

(The size in twips is optional and defaultsto 0.0.) There are two functions for setting the size in twips: you can passin a size in twips directly or in a graphics device map, which can be usedfor scaling, to convert the internally stored size in pixels to a size in twips.These functions are defined as follows:void SetSizeInTwips(const MGraphicsDeviceMap* aMap);void SetSizeInTwips(const TSize& aSizeInTwips);Functions are provided to set and access all the bitmap properties andalso to internalize and externalize bitmaps using streams. CGraphicsContext requires that any graphics device (and hence any graphicscontext) can do four basic operations with any CFbsBitmap object.The DrawBitmap functions of CGraphicsContext draw in one of thefollowing fashions:• from the source bitmap to a region of the device identified by itstop-left corner; the draw size depends on its size in twips, which mustbe specified; the target device converts from twips to pixels, whichmeans that the bitmap can be drawn according to an actual size,regardless of the twips-to-pixels mappings of the source and target• from the source bitmap to a region of the device identified by itsbounding rectangle; the bitmap is scaled to fit the target rectangle,which is specified in pixels• from a rectangular region of the source bitmap to a rectangular regionof the device; the bitmap region is scaled to fit the target rectangleand both rectangles are specified in pixels.You can also use a bitmap in UseBrushPattern(), for backgroundpainting.The GDI defines a bitmapped graphics device, CBitmapDevice,and a bitmapped graphics context, CBitmapContext.

You can readpixels and scan lines from a CBitmapDevice and create a CBitmapContext for drawing. You can perform actions such as clear, copyrectangles, blit and ‘blit under mask’ to a CBitmapContext. (Theblit-under-mask functions are used for drawing icons with transparentbackgrounds.) CBitmapContext::BitBlt() always does one-to-onepixel blitting, regardless of pixel size. Compare it with CGraphicsContext::DrawBitmap(), which always scales if it needs to, even whencopying from a bitmap to a bitmapped device.Bitmaps are managed by the font and bitmap server. Pre-built bitmapsare built into MBM files, from Windows BMP files, using bmconv – usuallyone per application or component. MBM files can be built into ROM ina format corresponding to the bitmap layout of the Symbian OS device’sDEVICE- AND SIZE-INDEPENDENT GRAPHICS549normal 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 shared heapof the font and bitmap server (FBS) as needed, before being blitted elsewhere.