When pressing Shift+Up(Down) should create a selection to the start(end) of the document when the caret position is on the first(last) line. Currently, in this case, a selection is not created.

Such behavior can be achieved using the following approach:

        private void RadRichTextBox_CommandExecuting(object sender, CommandExecutingEventArgs e)
        {
            if (e.Command is MoveCaretCommand && System.Windows.Input.Keyboard.Modifiers == ModifierKeys.Shift)
            {
                var command = e.Command as MoveCaretCommand;
                MoveCaretDirections direction = (MoveCaretDirections)e.CommandParameter;
                if (direction == MoveCaretDirections.Up)
                {
                    var positionOnFirstLine = new DocumentPosition(this.radRichTextBox.Document);
                    positionOnFirstLine.MoveToFirstPositionInDocument();
                    if (this.radRichTextBox.Document.CaretPosition.Location.Y - positionOnFirstLine.Location.Y < 1)
                    {
                        this.radRichTextBox.Document.CaretPosition.MoveToPosition(positionOnFirstLine);
                        e.Cancel = true;
                    }
                }
                else if (direction == MoveCaretDirections.Down)
                {
                    var positionOnLastLine = new DocumentPosition(this.radRichTextBox.Document);
                    positionOnLastLine.MoveToLastPositionInDocument();
                    if (positionOnLastLine.Location.Y - this.radRichTextBox.Document.CaretPosition.Location.Y < 1)
                    {
                        this.radRichTextBox.Document.CaretPosition.MoveToPosition(positionOnLastLine);
                        e.Cancel = true;
                    }
                }
            }
        }

At this point, the FloatingUIContainers cannot be selected. Implement selection to enable the users to work easily with such elements.

Font weight, size and other current editing style properties are not preserved when document layout is performed, for example in the following cases:
- the document is in web layout mode and the controls is resized
- scroll bar changes its visibility.

Steps to reproduce:
- Set RadRichTextBox to Web layout mode.
- Type a word, select it and make it bold.
- Press enter and type a word
- Repeat the previous step until RadRichTextBox height is reached and scrollbar appear.
- Type a word.
Expected: The last word is bold.
Actual: The last word is not bold.

After performance investigation related to feedback item http://feedback.telerik.com/Project/143/Feedback/Details/171108 , one bottleneck was identified as redundant calls to internal methods for getting parent of a document element.

Available in LIB Version 2018.2.820.

The pgMar element might be present but the margin information might be missing as shown below:
<w:pgMar w:header="720" w:footer="720" />
At the moment this overwrites the section margin information with 0. Instead the margins should remain as is.

Fix available in LIB Version 2018.2.820.

The spacing between the letters is too big.

If the position is moved to the end of a paragraph by clicking with the mouse in the empty space just left of the paragraph text, sometimes the subsequent text input (typing, pasting) is inserted at the beginning of the next paragraph, instead of at the end of the clicked one. 

The issue is somewhat random and cannot be reproduced consistently, though it's not hard to reproduce if clicking and typing is fast enough.

Certain documents containing a table with a cell spanning on more than one row might cause the application to hang and throw OutOfMemoryException.

Workaround: Set SpacingAfter = 0 of the last paragraph in the table.

When the first table cell for a table row is vertically merged, the height of the row is exported improperly - instead the height of the row containing the beginning of the merged cell is exported.

This would enable the customers to track the content that is being inserted and decline its insertion if needed.

When the rtf document contains a table as the one below and the empty declaration is used in the following structure, the document cannot be imported:

{\fonttbl
{\f0 Verdana;}
{\f1 Times New Roman;}
{\f2 ;}
{\f3 Segoe UI;}}

The exception is reproduced only with specific custom fonts and is thrown by the ComputeSubset() method of the GlyphTypeface class with the following message: "file does not conform to the expected file format specification". However, we can handle the exception and export the font data using the base class.

Available in LIB Version 2018.2.820.

At the moment the table properties, including table, table row and table cell properties don't have size validation, i.e. it is possible to set them to negative or zero values. Validation should be added where necessary.

RichTextBox interprets the div tag by adding a new line upon its closing. However, when the content of the div tag is a br tag, the whole combination should be treated as one new line.

The RadNumericUpDown buttons are too small and the selected value is not visible. The issue is not reproducible in NoXaml.

Fix is available in LIB Version 2018.2.716.

Currently RadRichTextBox uses the .NET syntax for the date and time formatting of the code fields. When such strings are exported to or imported from RTF/DOCX, the date and time formatting switch should be converted according to the document format specifications (e.g. 17.16.4.1 Date and time formatting from OOXML specification). Examples of differences:

- 'tt' in .NET is converted to am/pm specifier for the current culture. In DOCX specification, this is denoted as 'am/pm'
- '/' in .NET is converted to date separator for the current culture. In DOCX specification, the symbol doesn't have special meaning, so it's always converted to '/'.

.NET date format strings: https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings

MS Word date format strings: 
https://support.office.com/en-us/article/insert-edit-and-view-fields-in-word-c429bbb0-8669-48a7-bd24-bab6ba6b06bb#bm9

Workaround (partial): Modify InsertDateTimeDialog to contain only formats which are compatible with MS Word.

When a table is created, exported to HTML and then imported, the cells become taller. The reason for this behavior is that the table is by default with style TableGrid. When the table is exported to HTML, the style is preserved, however, upon import the style properties are set as local and the style itself is lost. The style by default defines LineSpacing="1" and SpacingAfter="0" for the paragraphs in the table and these are not copied as local. 

This means that if there is a style set to the table that defines paragraph properties as well, these properties will be set.

When inserting a new row using the InsertTableRowBelow below, the expected behavior would be to copy the paragraph styles of the paragraphs in the cells in the existing row. However, the style of the newly created paragraph is initially set to null and at some later point it is set to Normal. This creates an issue when using an HtmlDataProvider, which does not become aware of the change and the source HTML does not become updated with the information that the paragraph has style null.

Workaround: set all paragraphs with style null to have Normal style:

                foreach (var paragraph in RichTextBox.Document.EnumerateChildrenOfType<Paragraph>())
                {
                    if (paragraph.Style == null)
                    {
                        paragraph.StyleName = "Normal";
                    }
                }

When inserting a new row using the InsertTableRowBelow below, the expected behavior would be to copy the paragraph styles of the paragraphs in the cells in the existing row. This works when there is a property set locally, e.g. the text is bold, but the paragraph style, e.g. Heading 1 is lost.

When content has a font-size applied in EM values and the UseDefaultStylesheetFontProperties property of HtmlFormatProvider is set to true, the imported content has pretty small values for font size.