[[BackLinksMenu]] [[TicketQuery(summary=HOT_TEXT_REDESIGN_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|)]] = Analysis = == Overview == * The current implementation of HotText still relies on the initial prototype for managing text - NaiveHotText. It is not acceptable for the final version of Sophie 2.0 for the following reasons. * Very big performance problems. * Most of the basic operations for manipulation of text are realized with linear complexity (O(n)). * NaiveHotText depends on ProLib, leading to useless recalculations. * Text layout performance. * Inappropriate internal representation, making the implementation of complex features (such as chaining, anchoring, etc.) hard. * Layout tending to become more and more complex after each new task. This would decrease the development speed at which the next tasks will be implemented. == Task requirements == * Complete and stable design of the new HotText. * Decomposing of this task to smaller weekly tasks. * Working prototype of the new HotText representation. == Task result == The result will be prototype source code and detailed documentation of the new design. == Implementation idea == * Create a design draft for the new HotText, including text layout. * Make the new HotText immutable and with new interface. * Add new representation meaning to HotPos and styles. * Implement concepts of a highlight, text interval and style interval. * Create a new module for the new HotText that separates the new logic so that the old one is working until a full implementation. * Add tests and consider testing scenarios and performance measurements to check before and after the refactoring. == Related == * [wiki:GROUP_RESOURCE_MODEL_REDESIGN_R0] * [wiki:GROUP_BOOK_MODEL_REDESIGN_R0] == How to demo == The task is redesign so there will be no special scenario to demonstrate. = Design = * Design draft for the new HotText: [http://pastebin.asteasolutions.net/m71d8538c] * A new class ImmHotText is created, representing the text in Sophie2. * It is immutable. * Contains the represented text as an immutable tree (ImmTree) of characters assuring O(log n) complexity for the main operations. * Contains the style of the text. * It is represented as a mapping between style attributes (HotAttr) and a sorted set of style values. * The style values are ordered by HotPos. * HotStyleDef that can be applied to a text is a mapping between style attributes (HotAttr) and style values. * The value of an attribute is applied for all HotIntervals (from HotPos to HotPos) for the whole text. * When modifying the map the idea is that the last value of a specific attribute for a specific HotInterval is stored, the existing ones on these HotPoses are discarded (in other words no derivation is considered for the attribute at each position range). * ImmHotText can be converted to AttributedCharacterIterator, containing the text with all the style values applied for all attributes. * This way ImmHotText can be drawn at once on the graphics (not atom by atom). * It supports a change history using the following * Unique id * Reference to the previous text * Last operation (ElemOp). Could be * DeleteOp * InsertOp * NoOp (being a change that does not modify the text itself, e.g. access, applying styles, etc.) * Indexing * Each HotPos knows the id of the text it belongs to and its index in this text. * It could be indexed into every text using the last operation and the reference to the previous text with complexity O(n). It will be usually better because * It is with higher probability that the last used texts are searched. * Each queried HotPos is cached in a map, so a HotPos is searched only once in a specific text. * Note: In a later revision ImmHotText could support a list of operations instead of a reference to the previous text * HotPoses are split into different types: * AT - position of the character itself * Has index 4k * Used for operations on the text content (e.g. access) * BETWEEN - position between two characters * Has index 4k + 2 * Used for operations on the text content (e.g. modification - insert, delete, replace) * STYLE_AFTER - styling position after a character * Has index 4k + 1 * Used for styling operations on the text * STYLE_BEFORE - styling position before a character * Has index 4k + 3 * Used for styling operations on the text * This way all operations as completely and clearly defined for the text including: * Access * Replace * Insert * Delete * Styling * For a text range * Between two characters * At the beginning of the text (after the document character) * At the end of the text (before the document character) [[Image(positions.png)]] * Supports the basic text operations * Replace of a part of text (HotInterval) * SubText * ApplyStyle to a part of text [[Image(source:/branches/private/vlado/hottext-r4/sophie2-platform/doc/uml-design-diagrams/hotText/redesign/hottext.png)]] * A new HotLayout class is added to represent the text layout for the client code. * Internally it delegates to HotTextLayout class. * The responsibility for text layout is split into classes at different layout level * Text * Splits the whole text into areas (fairly complex - should be based on global criteria). * Delegates the text parts to the area layouts. * Delegates drawing to the area layouts. * Area * Splits the input text into lines (fairly complex - should be based on local area criteria). * Delegates the line texts to the line layouts. * Delegates drawing to the line layouts. * Line * Splits the input text into segments (fairly complex - should be based on local line criteria). * Delegates the segment texts to the segment layouts. * Delegates drawing to the segment layouts. * Segment * Stores: * The amount of the input text which can fit (consumed text). * The size of the segment. * The current highlights. * Draws the text. * Layout algorithm * Start with a greedy layout * Fill characters as much as possible on all levels (text, area, line, segment) * In the process do not allow word breaking (will be considered after the prototype implementation) * When splitting the area text into line texts consider that all lines between two breaks (line, para, doc break) are with equal height (simplification). * When checking if a text fits into an area consider the bounding rectangle of all atoms of the text (simplification). * Improve layout '''in a next step each''' considering (in order of importance): * Left, right and center alignment * Justified alignment * Hyphenation * Better line height * Better line fit (consider the actual area of all atoms of the text, not their bounding rectangle) * Vertical align * Tracking correction * Kerning correction * Deal with widows and orphans (last line of a paragraph in a new page is not a good layout) [[Image(source:/branches/private/vlado/hottext-r4/sophie2-platform/doc/uml-design-diagrams/hotText/redesign/layout.png)]] * Data, helper and util classes [[Image(source:/branches/private/vlado/hottext-r4/sophie2-platform/doc/uml-design-diagrams/hotText/redesign/data.png)]] * Enumerations * Attributes * Characters - all special characters are represented as char (int - representation discarded). [[Image(source:/branches/private/vlado/hottext-r4/sophie2-platform/doc/uml-design-diagrams/hotText/redesign/elements.png)]] * MVC * '''Note:''' The following are design considerations strongly related to [wiki:GROUP_BOOK_MODEL_REDESIGN_R0]. They will be defined in more details in a later revision or as part of the specified related task. * Model - follow the design specified in [wiki:GROUP_BOOK_MODEL_REDESIGN_R0] * Add an abstract class TextFrame related to text resource. * Add a class HeadTextFrame extending TextFrame to represent a text frame which has no chaining or is a head of a chain. * Add a class TailTextFrame extending TextFrame to represent a text frame which is a tail of a chain (any frame except the chain head). * View * The view drafts can be found at: [http://pastebin.asteasolutions.net/m57a7f3e5] * A new abstract HotTextView class is created to define common view logic for all text views. * A new interface SceneTextView is created to provide scene interface for the concrete views. * A new abstract class BaseTextView extending HotTextView is created for all text views that own their representation. * It Includes a TextViewHelper which encapsulates the operations on the model and provides an interface for the TextView to use. It has the following functionality: * Reference to ResourceAccess to be able to query the text resource. * model() auto property * A new abstract class PartTextView extending HotTextView is created for all text views that are represented as children to another (base) view. * HeadFrameView extends BaseTextView and implements SceneTextView to represent a text frame view which has no chaining or is a head of a chain. * TailFrameView extends PartTextView and implements SceneTextView to represent a text frame view which is a tail of a chain (any frame view except the chain head). [[Image(source:/branches/private/vlado/hottext-r4/sophie2-platform/doc/uml-design-diagrams/hotText/redesign/views.png)]] * Logic * A new HotTextLogic class is created to: * handle all events related to HotText. * fires a new event (more concrete) containing the new ImmHotText and the new view state. * For each operation create a new logic class to handle the events fired from HotTextLogic. * They contain simple logic to apply the modifications to the model and the view. * Testing * Demo tests - in org.sophie2.author * Unit tests - in org.sophie2.base.model.text * UML design diagrams are committed in a clean branch at: [4692], [4696] = Implementation = * Implementation of the prototype is in the second refactoring branch. Changesets: * [5475] * [5476] * [5481] * [5482] * [5612] * [5613] * [5626] * Known bugs to be fixed in the following revisions * OutOfMemory error (related to performance tuning). * Caret is displayed in the beginning of each segment. * Text layout functionality for getHitPos, getPosPlace and getLineEnds has bugs. * Views and Logics designs are changed, but not stable. It is to be specified in details in the design section of the next revision. * Testing * The current prototype should be tested for the functionality of the new text itself, not the mvc (although there is related code). * Use SwingDemoTest for checking the following functionality: * Layout * Should not break words (default left alignment) * Performance * Navigation - has bugs with UP, DOWN, HOME, END * Selection * Styling - can be tested by uncommenting lines in the demo. * For the next revision: * Integrate text with new resources * MVC design and implementation * Copy/Paste * Improved performance * Bug fixing = Testing = ^(Place the testing results here.)^ = Comments = ^(Write comments for this or later revisions here.)