When creating a field with local run properties, those properties are not applied to the field characters and they are left with the default properties.

When paragraphs in list and with hanging indent set are imported from RTF, unexpected values for hanging indent and left indent are imported. The problem is most visible when the document is exported to HTML and visualized in browser, as bullets of the list appear over the content.

Paragraph with a negative left indent and positioned in the header or footer gets clipped when exported to PDF. The same behavior is also observed for paragraphs in tables. Instead, the paragraph should be rendered without clipping.

When a paragraph has defined tab stops in its style and has the same tab stops locally cleared, the tab stops are still respected when exporting to PDF. Instead, cleared tab stops should not be respected.

When table cell preferred width is smaller than the first word in the cell the actual exported width should fit the word width when exporting to PDF. 

Currently in such case the word is split into two lines. The width has to be equal to the word width so the word stays on a single row.

When a style doesn't have explicitly defined font, the font from the default character properties (\defchp) is used when present. Instead, the font used for the style should be the default font for the document, defined with \deffN tag.
The same issue occur when the doesn't contain \defchp at all. In this case, the font for the style is not imported, but instead the defined with  \deffN tag should be used.

The construction is not common, and MS Word for example doesn't produce such documents.

The font size in the table does not respect the CSS for the corresponding class. There is similar issue with <li /> element. 

Style properties defined in an element style selector are evaluated with higher priority over properties in a CSS class when importing from HTML.

For example if we have the following CSS style:

.sectionheading {
border: 10px solid red;
        }
td {
border: 10px solid black;
        }
and the class (.sectionheading) is applied on a table cell:

<td class="sectionheading">...</td>

The result in WordsProcessing after import of such HTML will be that the table cell has 10px black border. In MS Word and in the browsers (Chrome, Firefox...) the result will be that the cell has 10px red border.

KeyNotFoundException is thrown when importing RTF document where single font info is not declared in group, for example the following RTF doesn't work:
{\rtf1\ansi\ansicpg1250\deff0{\fonttbl\f0\fswiss Helvetica;}\f0\pard test\par}

while the following works:
{\rtf1\ansi\ansicpg1250\deff0{\fonttbl{\f0\fswiss Helvetica;}}\f0\pard test \par}

This is valid according to RTF specification, which allows omission of the group when only:
<fonttbl>  '{' \fonttbl (<fontinfo> | ('{' <fontinfo> '}'))+ '}'

Content is moved from the second page to the first after applying styling to the footer and exporting to PDF format

This is done due to wrong column widths weights calculations.

When list level items are empty - <li></li> - they are not imported as empty paragraphs in list. The expected is that a Paragraph, associated to a list to be imported.

The paragraphs in RadFlowDocument can have paragraph borders. These borders are not exported when exporting the document to PDF. 

An empty paragraph is exported with different font size than the one coming from its style. The character properties should come from the style system.

Workaround: Add at least one space in each empty paragraph.

Currently empty paragraphs are exported to HTML with one space inside. Such paragraphs are not rendered by the browser. Such paragraph should be exported to HTML with one non-breaking space (@nbsp;) inside to ensure that they are visible in the browser.

Workaround: manually add nbsp-s in all empty paragraphs:
paragraph.Inlines.AddRun("\u00a0");


Steps to reproduce:
- Create document with empty paragraphs:

                        var document = new RadFlowDocument();
                        Section section = document.Sections.AddSection();
                        section.Blocks.AddParagraph();
                        section.Blocks.AddParagraph();
                        section.Blocks.AddParagraph();
                        section.Blocks.AddParagraph().Inlines.AddRun("test");

- Export it to HTML.

- Load the HTML in a browser.

Expected: The word 'test' is preceded by 3 empty rows.

Actual: The word 'test' is on the first row.

Table's 'cellspacing' and 'cellpadding' are not imported from HTML when the unit is not specified, e.g. <table cellpadding="25">. According to the HTML Specification (https://www.w3.org/TR/REC-html40/struct/tables.html#adef-cellspacing), the only permitted values are:
- only number
- number followed by percent.

MS Word imports it according to the specification (like WordsProcessing), but all of the browsers successfully imports values even with the px suffix, e.g. '25px'.

If the Table's TableCellSpacing property is not divided by 2 when the document is exported to Docx or Rtf, this leads to incorrect rendering after the exported document is opened with another editor (RadRichTextBox, MS Word).

Workaround: Divide by two the Table's table cell spacing property value before export to Docx, RTF formats:
foreach (Table table in document.EnumerateChildrenOfType<Table>())
{
    table.TableCellSpacing /= 2;   
}

In case table cell doesn't have directly applied background, it should inherit the background of its parent table.

When a document produced with WordsProcessing is validated with OpenXML Validator from OpenXML SDK, errors are found.

While documents are valid according to the specification, Open XML SDK Validation shows errors related to the order of elements, etc. Resolve all errors, so DOCX documents pass validation.