Add API for switching the flow direction of RadRichTextBox dialogs and mini tool bars. 

Currently this could be changed manually using the FlowDirection property, for example:

(this.radRichTextBox.ImageEditorDialog as ImageEditorDialog).FlowDirection = FlowDirection.RightToLeft;

but the result could be unexpected for Right-to-left.

Include the calculation of table borders into table layout. The result should be that the borders do not affect the height and width of the row/cell.

As a result, table is visualized in RadRichTextBox with extremely large column widths.

When document model is used in multi-threaded scenario, all image sources need to be frozen. Expose a method that does that out of the box.

Workaround: Solution with the public API available is in the attached freezeImagesInRadDocument.zip. 

The scenario is very common, as in MS Word the option Table -> Layout -> Cell Size -> AutoFit ->  "AutoFit Contents" changes the PreferredWidth of the table and its columns to Auto.
Also the tables imported from HTML have these properties set by default.

Scenarios:
- Auto-sized table occupies minimal space.
- All auto-sized columns in a table (table itself could be, or could be not, auto-sized) should always be sized proportionally to their content length. Currently, such columns are sized equally in the case when there is enough space for all of the content, which is unexpected. (also see the attached images for the scenario with fixed-width table + auto-sized columns).

Importing a document containing <pre> should interpret it as paragraph with specific (preformatted) style applied.

This results in prompt to save the changes when closing the file.

The fix is available in our latest LIB(v. 2014.3.1222).

"Based on style" combobox is not filled with all linked and paragraph styles in the following cases:
- "Modify style" dialog doesn't display the possible "based on" styles in the combobox when editing linked styles. 
- "Create new style from formatting" dialog doesn't display the possible "based on" styles in the combo box during creation of new linked style.

Steps to reproduce:

Variant 1:
- Click Home -> Styles -> Change Styles in the ribbon UI.
- Expand the the drop down of Heading 1 button and click 'Modify'
Expected: 'Style based on' combobox contains all paragraph and linked styles.
Actual: 'Style based on' combobox is empty.
-------------------
Variant 2:
- Click Home -> Styles -> Change Styles in the ribbon UI.
- Click 'New' button.
- Choose 'Style type:' Linked in the combobox.
Expected: 'Style based on' combobox contains all paragraph and linked styles.
Actual: 'Style based on' combobox is empty.

The fix will be available in our official release Q1 2015.

When inserting text (document fragment) next to a correctly spelled word they get both underlined as incorrect.

When ignoring incorrect words through the Spelling dialog and you reach the last word in the document which is incorrect, only one more word from the beginning of the document is checked prior showing a message that the check is complete. Instead, all incorrect words starting from the beginning of the document should be spellchecked. 

The issue is reproduced when adding the incorrect words to the dictionary. In order to reproduce the issue, only "Ignore" or "Add to Dictionary" action should be applied. When the actions are mixed, the issue is not reproduced.

Workaround: before opening the spellchecking dialog, move caret at the beginning of the document
this.radRichTextBox.Document.CaretPosition.MoveToFirstPositionInDocument();

The issue is reproduced with Marathi IME. Type some letters, press and release shift, then press space. The result is that the current IME text is duplicated. 

Currently, CopyHyperlink command (Context menu over hyperlink -> Copy Hyperlink) puts hyperlink text in plain text format in the clipboard. Instead, it should put the URI. This way when the user pastes in a plaint text editor, they will get the URI.

Workaround: The user could copy the text from the Edit Hyperlink dialog instead. 

Decimal tab stops are aligning numbers to the thousands separator (,) instead of to the decimal point (.).
The fix will be available in the next official release Q3 2014

The fix is available in our latest LIB release (v. 2015.01.0413).

UpdateAllFields method causes StackOverlfowException when:
- there are two TOC fields in the document with specific location (no paragraphs between the two fields)
- when merge fields containing new lines ('\r\n') are updated.

UpdatField method causes StackOverlfowException in the IntervalTree class when:
- A TOC field is updated and the field contains field separator (<w:fldChar w:fldCharType="separate"/>) in its definition. The exception is reproducible when there are section breaks before the TOC. 

Fix available in LIB Version 2017.2.627.