When document fragment containing consecutive spans with same style is inserted with RadRichTextBox.InsertFragment method, and the document is with specific structure (which is not exactly known), NullReferenceException in HierarchicalIndex.GetBoxByHierarchicalIndex could be thrown when text is typed in specific places in the document.

Workaround: Ensure that such spans are merged before creating the fragment:

var document = xamlProvider.Import(xaml);
document.MergeSpansWithSameStyles();
var fragment = new DocumentFragment(document);
rtb.InsertFragment(fragment);

---------------------------------------

Sample call stack:

System.NullReferenceException
 at Telerik.Windows.Documents.HierarchicalIndex.GetBoxByHierarchicalIndex(DocumentLayoutBox documentBox, HierarchicalIndex hierarchicalIndex)
 at Telerik.Windows.Documents.DocumentPosition.RestorePositionFromBoxIndex(Nullable`1 raiseEvent)
 at Telerik.Windows.Documents.Model.RadDocumentEditor.InsertTextInternal(String text, Span currentSpanStyle, Boolean explicitAcceptsReturn)
 at Telerik.Windows.Documents.Model.RadDocumentEditor.InsertFromUI(String text, Span currentSpanStyle, Boolean acceptsReturn)
 at Telerik.Windows.Controls.RadRichTextBox.Telerik.Windows.Documents.UI.ITextInputCommandsHandler.InsertText(String text)
 at Telerik.Windows.Documents.UI.CaretTextInputHandler.InsertText(String text)
 at Telerik.Windows.Documents.UI.CaretTextInputHandler.HandleTextInsertedWithoutIme(RadDocument document, String text)
 at Telerik.Windows.Documents.UI.CaretTextInputHandler.CaretUI_TextInserted(Object sender, TextInsertedEventArgs e)
 at Telerik.Windows.Documents.UI.Caret.OnTextInserted(Object sender, TextInsertedEventArgs e)
 at Telerik.Windows.Documents.UI.Caret.OnTextChanged()
 at Telerik.Windows.Documents.UI.Caret.Caret_TextChanged(Object sender, TextChangedEventArgs e)

...

Fix available in LIB Version 2018.2.813.

When a table is on a page different than the first one and user clicks on the thumb for resizing the table row height, wrong value is calculated and passed to the setter of the TableRow's Height property.

This leads to wrong table layout when the document is exported using RtfFormatProvider.

The RTF specifications states that the header of the document should start with "\rtfN" where N is the version of the RTF. Currently, the RtfFormatProvider do not save the version, but only "\rtf". Most software handles this case, but in some cases the document cannot be read.

When a text doesn't specify font explicitly with \fN tag, and default character properties (\defchp) are not specified, or are specified but without font set, the font of the text is visualized with the default font - Verdana. Instead, the default font for the document should be used - defined with \deffN tag.

RadRichTextBox doesn't render a border that is not locally defined. In this case, the corresponding border from the applied table style should be used.

A paragraph is exported to HTML with properties from its bullet when the default document properties are customized. Here are the steps to reproduce:

Change the document default font-size to 10.5 pt(14px).
Change the document default font-family to "Calibri".
Add two paragraphs with text.
Apply a list to the paragraphs
Export to HTML 
Import the resulted HTML.

Observed: The paragraphs text is with font-family "Verdana" and font-size of 12pt
Expected: The paragraphs should inherit its font properties from the document default properties.
You could also check the attached Observed and expected screenshots.

We have a legacy system that generates RTF using some native RTF controls. The RTF generated by this application is compatible with MS wordpad. But seems that the RadRichTextBox is not compatible. The problem is when we use bullets.

Consider we create an RTF with bullets, using legacy -

   * Legacy Bullet 1
   * Legacy Bullet 2
   * Legacy Bullet 3

Then, this is the RTF that is generated -

{\rtf1\fbidis\ansi\ansicpg1252\deff0{\fonttbl{\f0\fnil\fcharset0 Segoe UI;}{\f1\fnil\fcharset0 Arial;}{\f2\fnil\fcharset2 Symbol;}}

{\colortbl ;\red0\green0\blue0;}
\viewkind4\uc1\pard\ltrpar\cf1\lang1033\f0\fs22\par
\pard{\pntext\f2\'B7\tab}{\*\pn\pnlvlblt\pnf2\pnindent0{\pntxtb\'B7}}\ltrpar\fi-200\li200\tx360 Legacy Bullet 1\par
\pard{\pntext\f2\'B7\tab}{\*\pn\pnlvlblt\pnf2\pnindent0{\pntxtb\'B7}}\ltrpar\fi-200\li200\tx360\tx360 Legacy Bullet 2\par
\pard{\pntext\f2\'B7\tab}{\*\pn\pnlvlblt\pnf2\pnindent0{\pntxtb\'B7}}\ltrpar\fi-200\li200\tx360\tx360\tx360 Legacy Bullet 3\par
\pard\ltrpar\tx360\tx360\tx360\par
\f1\par
}
----------------------------------------------------------------------

Now, if we open this RTF in Wordpad, then the bullets are displayed correctly.

But the bullets are not displayed when we bind the RTF to RadRichTextBox.

It displays something like this -

Legacy Bullet 1
Legacy Bullet 2
Legacy Bullet 3

And after binding the original RTF, if we now try to get the RTF this is how it looks like - 

{\rtf\ansi\ansicpg1252\uc1\deff0\deflang1033{\fonttbl{\f0 Verdana;}{\f1 Segoe UI;}{\f2 Arial;}}{\colortbl\red0\green0\blue0 ;;}{\*\defchp\ltrch\f0\fs24\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone}{\*\defpap\sl276\slmult1\sa180}{\stylesheet{\s0\sqformat\spriority0\ltrch\f0\fs24\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\sl276\slmult1 Normal;}{\*\ts2\tsrowd\spriority59\trbrdrt\brdrnone\trbrdrb\brdrnone\trbrdrl\brdrnone\trbrdrr\brdrnone\trbrdrh\brdrnone\trbrdrv\brdrnone\trgaph0\clpadft3\clpadt0\clpadfr3\clpadr0\clpadfl3\clpadl0\clpadfb3\clpadb0\tsvertalt\ltrch\f0\fs24\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\sl276\slmult1 Table Normal;}}\nouicompat\viewkind4\paperw12240\paperh15840\margl1425\margr1425\margt1425\margb1425\deftab720\sectd\pgwsxn12240\pghsxn15840\marglsxn1425\margrsxn1425\margtsxn1425\margbsxn1425\headery720\footery720\pard\s0\ltrpar\sl240\slmult1{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\par}\pard\s0\ltrpar\tx360\sl240\slmult1\li200\lin200\fi-200{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone Legacy Bullet 1}{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\par}\pard\s0\ltrpar\tx360\sl240\slmult1\li200\lin200\fi-200{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone Legacy Bullet 2}{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\par}\pard\s0\ltrpar\tx360\sl240\slmult1\li200\lin200\fi-200{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone Legacy Bullet 3}{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\par}\pard\s0\ltrpar\tx360\sl240\slmult1{\ltrch\f1\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\par}\pard\s0\ltrpar\tx360\sl240\slmult1{\ltrch\f2\fs22\i0\b0\strike0\cf0\cb1\highlight1\ulc0\ulnone\par}}

-Amul.

When an enter is pressed the paragraph is split into two parts and does not apply the current editing style to the formatting symbol of the first part.

Steps to reproduce:
Add text to an empty paragraph.
Increase the font-size.
Press enter.

Expected result: If the user starts to write the text should have its font properties from the current editing style. 

Expected result 2: If the client moves the caret around and then return to the beginning of the second paragraph it and start writing, the text should have its font properties from the formatting symbol(which are applied from current editing style when the paragraph has been split). 

When the preferred width of the table is set to a percentage value and the columns inside have preferred width values in pixels, the bigger width should take precedence when showing the table. At this point, the table column widths are with higher priority.

RadRichTextBox/RadDocumentEditor's MailMerge(bool) method doesn't respect the startEachRecordOnNewPage parameter. When the parameter is set to 'false', records are still merged on different pages, instead of on one.

Workaround: Use RadDocumentMerger to append the resultant documents:
http://docs.telerik.com/devtools/wpf/controls/radrichtextbox/features/merge-documents/append

When the control is used in NoXaml scenario and the required resources are merged in the resources of the Window/UserControl containing RadRichTextBox, XamlParseException is thrown at runtime with a message "Cannot find resource named 'thumbStroke'."
or
the App.Current.Resources.MergedDictionaries is cleared.

Workaround: Merge Telerik.Windows.Documents.xaml and Telerik.Windows.Controls.RichTextBoxUI.xaml in App.xaml.
or
Merge the resourced before initializing RadRichTextBox:
 App.Current.Resources.MergedDictionaries.Add(new ResourceDictionary()
            {
                Source = new Uri("/Telerik.Windows.Documents;component/Themes/Styles/ImageAdornerUIResourcesDictionary.xaml", UriKind.RelativeOrAbsolute)
            });


Fix available in R3 2017 Official Release version.

In Word and WordPad when hitting Ctrl+Down Arrow the cursor moves to the start of the next paragraph, until the last paragraph in the document where it moves to the end of the document. In Telerik editor it moves to the end of the paragraph.

Steps to reproduce:
- Load a document with multiple lines of text
- Click near the top of the document and hit Ctrl+Down repeatedly

Expected: The cursor moves down one paragraph at a time with the cursor at the start of the paragraph
Actual: The cursor moves down one paragraph at a time with the cursor at the end of the paragraph

Fix available in LIB Version 2017.3.1218.

Mail merge is not working for the first record in the items source when the items source is IEnumerable with deferred execution.

Workaround: convert the collection to list.

"Win32Exception (0x80004005): Not enough storage is available to process this command" is thrown when multiple RadDocument instances are created in background threads. 

This is due to the fact that RadDocument contains MailMergeDataSource object, which is DependencyObject. When multiple dependency objects are created in different threads, they are not property freed by thread's Dispatcher.

Workaround 1: Microsoft provided workaround in a bug report here:
https://connect.microsoft.com/VisualStudio/feedback/details/620588/system-componentmodel-win32exception-0x80004005-not-enough-storage-is-available-to-process-this-command , namely:
------------------------------
Put the following code:

Dispatcher dispatcher = Dispatcher.CurrentDispatcher;
dispatcher.BeginInvokeShutdown(DispatcherPriority.Normal);
Dispatcher.Run();

anywhere in the background thread processing the RadDocument.
-----------------------------

Workaround 2: Use pooling of the used threads. The problem is that Task Parallel Library (which has built-in pooling) does not use STA threads by default, but this can be achieved by using custom TaskScheduler (attached, the code is get from here: https://code.msdn.microsoft.com/ParExtSamples ):

            var parallelOptions = new ParallelOptions()
            {
                TaskScheduler = new StaTaskScheduler(Environment.ProcessorCount)
            };

            Parallel.For(0, 10000, parallelOptions, cc =>
            {
                    var document = new DocxFormatProvider().Import(data);
                    byte[] pdfBytes = new PdfFormatProvider().Export(document);

            };

Using Microsoft Pinyin IME for typing in the RichTextBox causes FatalExecutionEngineError exception. 

The content of the table cells seems to be rendered in the correct position while the borders are drawn above the continues section break.

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.

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.

Add the following code to an application with a RadRichTextBox in it:

for (var i = 0; i < 1000; i++)
{
    var doc = radRichTextBox.Document.CreateDeepCopy();
}

If your document does not contain any lists it behaves as expected: memory usage increases until the next GC when it is collected. If there are lists in your document the RadDocument instances created by CreateDeepCopy are never collected and your app will run out of memory.

Fix available in LIB Version 2018.3.1029.

 

First Scenario: During layout of specific documents where the first section is with Continuous section break type, the layout algorithm enters in an infinite loop causing the application to hang.

Workaround: Change the section break type for the first section after the import of the document and before the layout:

Second Scenario: During the layout of specific documents where the last section is with Continuous section break type and has specific page size width and height, the layout algorithm enters in an infinite loop causing the application to hang.

Workaround 2: Slightly modify the size of the section which causes the issue after the import of the document and before the layout:

Third Scenario: During layouting of specific documents containing anchored elements, the layout algorithm enters in an infinite loop causing the application to hang. No workaround.