<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept xml:lang="en" id="GUID-EDAF2886-5296-53BD-B847-0E0D9B5FBF7E"><title>Special requirements</title><prolog><metadata><keywords/></metadata></prolog><conbody><section><title>Performance</title> <p>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.</p> <p>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.</p> <p>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.</p> </section> <section><title>High-level GUI support</title> <p>For many purposes, such as editing short text objects, a GUI-provided high-level editor provides a convenient interface. </p> </section> <section><title>Text content interfaces</title> <p>The <xref href="GUID-51B3C34F-2F8E-3181-93C4-00F073B1207C.dita"><apiname>MLayDoc</apiname></xref> interface is used to convey layout information from a text object to the text layout and views. Within the Symbian OS 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.</p> <p>A further benefit is that any content model may be equipped with an <codeph>MLayDoc</codeph> interface. For instance, an HTML browser would require formatting that could be specified through the <codeph>MLayDoc</codeph> 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 <codeph>MLayDoc</codeph> interface.</p> </section> <section><title>Detailed view control</title> <p>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.</p> <ul><li id="GUID-21B3BAB1-3C84-5E62-8766-9860C00A0E1D"><p>the visibility of non-printing characters (paragraph marks, blanks, non-breaking blanks) can be controlled</p> </li> <li id="GUID-EC249206-5F64-599C-9271-6C31EE04194F"><p>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)</p> </li> <li id="GUID-C8B6EFC2-4808-584A-82B4-1A386175CEB6"><p>text can have highlighting applied to it, these highlights may have round corners</p> </li> <li id="GUID-60812D34-065A-5418-9456-3CCB340ED18B"><p>pictures may have frames, with or without grab handles, when selected</p> </li> </ul> </section> </conbody></concept>