The exception is thrown because the AltChunk element is added for import, but we currently do not have implementation for importing of AltChunk elements: https://feedback.telerik.com/Project/184/Feedback/Details/190095-wordsprocessing-add-support-for-altchunk-element

There is a discrepancy between RadWordsProcessing and MS Word:

row.Height = new TableRowHeight(HeightType.Exact, image.Image.Height); 

Importing shape with missing id attribute leads to NullReferenceException. 

 <v:shape type="#_x0000_t202" filled="false" stroked="false">

Table and table cell borders are not evaluated according to inheritance and conflict resolution rules. A conflict will occur when different borders from the table and table cell are overlapping. 

The GetActualValue method of the TableBorders and TableCellBorders could potentially return an incorrect value in some of the following scenarios:

Scenario 1:
A table has cell spacing set to 0. Meaning that the table and table cell borders will overlap.
The table borders have defined all of its borders with border style "Single".
The table cell borders have all of its borders defined with border style "None".

Expected result: the resulting borders should have the border style set to "None" for the location where the table and the cell borders are overlapping.

Scenario 2:
A table has explicitly defined that its right border is with border style "None".
The table has a table style applied with defined border style of type "Single" for all table borders.

Expected result: All of the table borders except the right border should have border style of "Single".

The problem is mostly visible when exporting to PDF and RTF format.

The empty lines are not converted properly from RTF to HTML

Workaround: 

Borders are not correctly imported from HTML.

Workaround: Set borders in code:

var tables = document.EnumerateChildrenOfType<Table>();

var border = new Border(1, BorderStyle.Single, new ThemableColor(Colors.Black));

foreach (var table in tables)
{
    table.Borders = new TableBorders(border);

    foreach (var row in table.Rows)
    {
        foreach (var cell in row.Cells)
        {
            cell.Borders = new TableCellBorders(border);
        }
    }
}

Revisions in WordprocessingML provide a mechanism for storing information about the evolution of the
document (i.e. the set of modifications made to a document by one or more authors).

This element specifies that this run contains literal text which shall be displayed in the document. The delText
element shall be used for all text runs which are part of a region of text that is contained in a deleted region
using the del element.

This is the preview (This is deleted text) of the following XML:

<w:p>
	<w:r>
		<w:t xml:space="preserve">This is </w:t>
	</w:r>
	<w:del w:author="Cooper W.">
		<w:r>
			<w:delText>deleted text</w:delText>
		</w:r>
	</w:del>
</w:p>

Dear all,

It seems that the RtfFormatProvider generates invalid alternative text in the "{\listtext }" RTF group when saving a RadFlowDocument that contains numbered paragraphs.

The text seems to always be "{N}" when level N of the list is used.

While this is no problem for readers that adhere to the latest RTF standard, RichEdit-based controls and WordPad in Windows 8-10 have issues with it and do not load the list. These versions of RichEdit are otherwise capable of reading list tables.

Please note that I am not talking about loading the document to Windows 7 RichEdit, since that does not support list tables at all (it is stuck to the Word '95 "{\*\pn ...}" format).

I submit a simple list example that can be read by WordPad in Windows 10 and the outcome after loading and saving it back with RtfFormatProvider.

The outcome loads correctly in Word and RadRichtextBox, but not in WordPad. Removing or correcting the "{\listtext ...}" for each paragraph manually makes the list load properly in WordPad.

BTW, I strongly disagree with the nonexistent support for the Word '95 RTF numbering format, since it either forces us to use some other product or create our own code to parse and massage the RTF prior to loading into your products.

The problem is great, as many controls/products are still based on the RichEdit control (including some versions of our products).

It is not only old RTF data that needs migration, but pasted content from WordPad or other applications as well, since otherwise numbering is killed, without even displaying any text present in "{\pntext ... }" groups, intended for readers that do not understand "{\*\pn ...}".

Finally, to make things worse, even in Windows 10, RichEdit uses Word '95 format for saving single-level lists (resulting in content with mixed list formats).

Anyway, thank you for your time.