Extend the support for em units. Em is calculated relatively to the font-size style property.

When importing a simple table from HTML in Ms Word, it gets applied table cell spacing and margin. This makes it look more in the manner it does in a browser, i.e. the content of cells is vertically centered.

Check for TableCell, TableRow, and Table.

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

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.

Styled text in a list item <li> is imported as a different paragraph. The result is split of the text into multiple paragraphs which are not in a list.

The issue could be observed only when the text is written as a direct content of the <li> element. If it is in a <p> element the paragraph is imported correctly (it is not split). 

For example:

problematic html (the paragraph will be split) - <li>An appointment may create any provisions <strong>and</strong> in particular: </li>
non-problematic html (the paragraph will be imported as it should) - <li><p>An appointment may create any provisions <strong>and</strong> in particular: <p></li>

When the last run from a paragraph is underlined, the associated bullet has underline applied as well. The same applies for the background color.

If we have a list (<ol>, <ul>) with list items (<li>) and there is a paragraph inside a list item(<p>), an empty additional paragraph is imported if the <p> element is right next to the <li> element (without a space). The indentation of child paragraphs in list item could be messed up as well. If there is a space between the HTML elements, the content is imported as expected.

When importing an image whose Uri is not a full Uri, an exception is thrown.

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

Introduce an option to implement custom field in RadFlowDocument model (one which is not supported by the document model).

In the current implementation the abstract Field class has internal abstract method which is responsible for the GetFieldResult() method and this leads to an issue when a customer wants to implement a field which we currently do not support (CustomCodeField which returns null as a result fragment).

When some character is not supported by the font, the fallback mechanism should try finding some other font that is capable of rendering the unsupported character. However, RadPdfProcessing fallback mechanism does not always find the correct font which sometimes result in wrong glyph visualization or in missing glyph.

Workaround: Font that supports these special characters may be used. This way the fallback mechanism will not be needed to export the PDF text.

If Paragraph has applied style, and this style has associated list, and the paragraph is removed from the list locally, then on import the paragraph is added to the list.

The additional numbering could be removed from the paragraph by changing its style:

foreach (var p in this.document.EnumerateChildrenOfType<Paragraph>())
{
    if (p.ListLevel == 0)
    {
        var style = new Telerik.Windows.Documents.Flow.Model.Styles.Style("NoListStyle", StyleType.Paragraph);
        style.ParagraphProperties.CopyPropertiesFrom(this.document.StyleRepository.GetStyle(p.StyleId).ParagraphProperties);
        style.ParagraphProperties.ListId.LocalValue = null;
        style.ParagraphProperties.ListLevel.LocalValue = null;
        p.StyleId = "NoListStyle";
    }
}

When an image is moved to a location, different than the default one, this setting is not respected due to the missing margin property.

Introduce support for East Asia fonts.

In OOXML, table row can define table properties named 'table level property exception' using 'tblPrEx' element. These properties shall be respected by the row instead of the table properties defined on table level.

Add similar property in the TableRow model and respect it in the corresponding exports.

The 'border' attribute of Html <table /> is imported wrong. When set to 0, a 1px border is rendered. 

Add support for the <w:sym /> element, e.g.:

<w:r>
   <w:sym w:font="Wingdings" w:char="F0FC"/>
</w:r> 


From the specification:
"This element specifies the presence of a symbol character at the current location in the runs content. A symbol character is a special character within a runs content which does not use any of the run fonts specified in the rFonts element (17.3.2.26) (or by the style hierarchy).

Instead, this character shall be determined by pulling the character with the hexadecimal value specified in the char attribute from the font specified in the font attribute."

Currently such symbols are skipped during DOCX import.

Possible workaround: These tags are inserted from MS Word when the Symbol dialog in used. If the document is created with MS Word, the user could insert the symbol using the keyboard, in this case the character is inserted as a normal run.

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.

Import of Tables with border style needs improvements. Currently, it takes multiple seconds to import table with 100x6 cells no matter if the border style is defined globally or locally. This may be seen when importing the attached files "table with borders.html" and "table single border style.html". Importing the same table without borders is achieved in less than a second which may be seen with the attached "table without borders.html".