Since text objects are potentially both large and complex, editing them can involve complex operations. It is important on the one hand that text views have high performance, and on the other that they require little memory, and have a usable API.
Memory use is minimised by the format band and by using only minimal format information for purposes which require it — such as pagination, and print preview.
One key measure of perceived performance is responsiveness to user input. The Text Views API support this by using background-priority active objects to maintain the formatting of text in two contexts. Firstly, the formatting of the format band is handled, where possible, using an active object which is invisible to the user of the API. Secondly, pagination is handled, where required, using an active object which is visibly part of the API.
For many purposes, such as editing short text objects, a GUI-provided high-level editor provides a convenient interface.
The MLayDoc interface
is used to convey layout information from a text object to the text layout
and views. Within the Symbian platform text content model, global
text and rich text implement this interface. Using such a narrow interface
between content and views allows each to be optimized separately and is good
object-oriented design.
A further benefit is that any content model
may be equipped with an MLayDoc interface. For instance,
an HTML browser would require formatting that could be specified through the MLayDoc interface,
but for various reasons it may wish to use a substantially different content
model. One important reason is that HTML is essentially read-only. Other applications,
especially for data browsing, may also benefit from the flexibility of the MLayDoc interface.
The first requirement of text views is that they honor all the specifications of a text object and its formatting information. However, in addition to this, text views provides many flexible features for controlling the display of text.
the visibility of non-printing characters (paragraph marks, blanks, non-breaking blanks) can be controlled
background colour can be specified, and text colour overridden from that in the document, in accordance with user preferences (e.g., in order to display yellow text on a dark blue screen instead of the default black on white)
text can have highlighting applied to it, these highlights may have round corners
pictures may have frames, with or without grab handles, when selected