When exporting a DOCX file to PDF format, the following error message occurs:

InvalidOperationException when cloning a document containing fields spanning multiple paragraphs.

Workaround: instead of new paragraphs, use line breaks (Shift+Enter).

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.