Run's default constructor creates it with Text = null. When document with such run is exported to PDF, NullReferenceException is thrown.

Workaround: Create the Run and immediately set its Text property to string.Emtpy.

Available in LIB Version 2018.1.423.

Applying LockAspectRatio to an image is not respected after opening the document in MS Word - the LockAspectRatio checkbox in the is not checked. An additional XML element (cNvGraphicFramePr) should be added so the UI can respect it.

Add support for exporting hyperlinks which are not valid URIs to PDF. Currently such hyperlink URIs are not exported to the PDF document.

Example of such hyperlink is "mailto:abc%20abc-abc-abc%20%3cabc@abc.com%3e" (mailto:abc abc-abc-abc <abc@abc.com>), but there could be more types. Currently the internal API relies on creating instance of the system Uri class, which is not possible in this case.

Currently there is no easy way to modify the properties of bookmarks and fields in the document. Think of providing API for easier manipulation.

For example, following is one of the easiest approached to change the target of hyperlinks:

                    var hyperlinkStarts = document
                        .EnumerateChildrenOfType<FieldCharacter>()
                        .Where(fc => fc.FieldCharacterType == FieldCharacterType.Start && fc.FieldInfo.Field is Hyperlink);

                    foreach (var fieldCharacter in hyperlinkStarts)
                    {
                        int indexOfCodeRun = fieldCharacter.Paragraph.Inlines.IndexOf(fieldCharacter) + 1;
                        Run hyperlinkCode = (Run)fieldCharacter.Paragraph.Inlines[indexOfCodeRun];

                        string oldUri = ((Hyperlink)fieldCharacter.FieldInfo.Field).Uri;
                        string newUri = "mailto:mail@mail.com";

                        hyperlinkCode.Text = hyperlinkCode.Text.Replace($"\"{oldUri}\"", $"\"{newUri}\"");
                        fieldCharacter.FieldInfo.UpdateField();
                    }

If the background color is applied to <tr> element then it is not imported.

Workaround: The background color may be applied to the cells (<td> elements) in the desired row and this should have the same effect.

When importing paragraphs with negative text-indent from HTML, e.g. 
<p style="text-indent:-12px;">
test
</p>

they should be imported with HangingIndent + the same value with negative sign for LeftIndent, e.g. HandingIndent: 12 AND LeftIndent: -12.

Also, margin-left should be combined with the text-indent, e.g.
<p style="margin-left: 16px;text-indent: -16px;">
test
</p>
should be imported as HandingIndent: 16 AND LeftIndent: 0.

This element specifies that the nearest ancestor structured document tag shall be of a document part type.

<w:sdt>
<w:sdtPr>
…
<w:docPartObj>
…
</w:docPartObj>
</w:sdtPr>
…
</w:sdt>
The docPartObj element in this structured document tag's properties specify that the type of structured document tag is a document part. The child elements must specify the gallery and category semantics for this part, if any.
Currently, such elements are skipped on import.

When paragraph contains only merge fields (and eventually whitespaces), and all of these fields are evaluated to empty string for particular data record, the paragraph could be removed from the merged document.

Example: The document contains two paragraphs:
<<FirstName>>
<<LastName>> <<Address>>

For particular data record, LastName and Address are empty, so the merged document for this data record will contain only one paragraph (the first one). This behavior is expected from customers, as it's implemented by MS Word.

At the moment when a Floating Image is exported to HTML, it is exported as inline and its position is lost.

Exporting to PDF of a table with a first cell having preferred width of 100% and a second cell having preferred width of auto will result in missing the second cell.

The issue is observed with tables that have a specific width (in inches or percents) but whose columns do not have width specified. MS Word renders such tables expanded to their full width. For tables with 100% width, they have to expand to the entire width of the page. The same behavior is expected in the PDF export.

As a common side effect, when specific text alignment (e.g. center or right) is applied to a paragraph within a table cell, and the table is with specified width, but the column is auto-sized (without set width), then the text alignment seems as not respected. Actually the problem is that the column table is shrunk to the text width.

Workaround: this may be used before exporting the RadFlowDocument instance to PDF:

foreach (Table table in document.EnumerateChildrenOfType<Table>())
{
    table.LayoutType = TableLayoutType.FixedWidth;
}


Workaround 2:

Set specific width to the auto-sized columns (to any of the cells in the columns):

cell.PreferredWidth = new Telerik.Windows.Documents.Flow.Model.Styles.TableWidthUnit(500);

Available in R1 2018 SP2 release version.

The table height is currently not respected when applied to a table element through an attribute or through a CSS style. This setting is not respected in the flow document model, but we could import it and calculate the value to distribute it to the rows.

The exception is thrown because we try to export a tblGrid element, but currently we do not support this: https://feedback.telerik.com/Project/184/Feedback/Details/190082-wordsprocessing-export-tblgrid-table-grid-property-for-table-elements

The theme xml element (root of the theme.xml part) has a name property which is optional. However, WordsProcessing throws an exception when it doesn't find a name.

When a document has a deleted text as part of track changes and there is a comment on the deletion, the document throws InvalidOperationException upon import.

When the current position is in the middle of a paragraph and the InsertSection() method is invoked, it should automatically split the content at the current position and transfer the content that is on the right side of the position to the new section along with all the following blocks. 

At this point, the method transfers only the content of the current paragraph and, if the section has following paragraphs, they are left in the "old" one.

Implement import of bullets and numbering which use the old Word 6.0/Word 95 format from RTF. This includes, but is not limited to, the following RTF tags: \pnlvlN, \pnlvlblt, \pnlvlbody, \pnlvlcont. See RTF specification, "Word 6.0 and Word 95 RTF" heading for full description.
WordPad and some legacy systems export lists with this formatting, so the construction is relatively widespread.
According to the specification, if RTF reader doesn't support specific bullets/numbering tags, it can use the \pntext tag to read the bullets/numbering as plain text; but currently WordsProcessing always ignores the \pntext tag. Because of this, the bullets or numbers of lists in the old format are missing after import.

Although this is not a valid table scenario we should not throw an exception when measuring and exporting such table.

Fix available in LIB Version 2017.3.1218.

Updating TOC field or any other CustomCodeField that has a result fragment spread on more than one paragraph will cause an ArgumentException.

This property will control whether a table row may start on one page and end on the next page.

Declined: Duplicate with https://feedback.telerik.com/Project/184/Feedback/Details/190081-wordsprocessing-respect-tablerow-cansplit-property-when-exporting-to-pdf.