Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro 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|) failed

current transaction is aborted, commands ignored until end of transaction block

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

• GROUP_RESOURCE_MODEL_REDESIGN_R0
• 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)

• Supports the basic text operations
  • Replace of a part of text (HotInterval)
  • SubText
  • ApplyStyle to a part of text

• 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)

• Data, helper and util classes

• Enumerations
  • Attributes
  • Characters - all special characters are represented as char (int - representation discarded).

• MVC
  • Note: The following are design considerations strongly related to 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 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).

• 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.)}