When you have indented and justified text, it is wrongly exported to PDF:

			<w:pPr>
				<w:spacing w:after="0" w:line="360" w:lineRule="auto"/>
				<w:ind w:left="567" w:right="567" w:firstLine="708"/>
				<w:jc w:val="both"/>
				<w:rPr>
					<w:rFonts w:ascii="Calibri Light" w:hAnsi="Calibri Light"/>
				</w:rPr>
			</w:pPr>

When converting HTML to DOCX, margins set on an HTML element are ignored. These styles are exported correctly when the HTML passed to the converter is formatted with indents. The following XUnit test demonstrates this behavior with a simplified example.

using Telerik.Windows.Documents.Flow.FormatProviders.Docx;
using Telerik.Windows.Documents.Flow.FormatProviders.Html;

namespace MSPI.Tests.Unit;

public class WordExportTest
{
    [Fact]
    public async Task TextExport()
    {
        const string formattedDocumentSavePath = @"C:\Testing\export-test-formatted.docx";
        const string formattedContent = """"
            <p>Test paragraph</p>
            <ol style="margin-left: 100px;">
                <li>Item 1</li>
                <li>Item 2</li>
            </ol>
        """";

        const string minifiedDocumentSavePath = @"C:\Testing\export-test-minified.docx";
        const string minifiedContent = """"<p>Test paragraph</p><ol style="margin-left: 100px;"><li>Item 1</li><li>Item 2</li></ol>"""";

        var htmlFormatProvider = new HtmlFormatProvider();
        var docxFormatProvider = new DocxFormatProvider();

        await using var minifiedDocumentMemoryStream = new MemoryStream();
        var minifiedRadFlowDocument = htmlFormatProvider.Import(minifiedContent, TimeSpan.FromSeconds(30));
        docxFormatProvider.Export(minifiedRadFlowDocument, minifiedDocumentMemoryStream, TimeSpan.FromSeconds(30));
        var minifiedBytes = minifiedDocumentMemoryStream.ToArray();
        await File.WriteAllBytesAsync(minifiedDocumentSavePath, minifiedBytes);

        await using var formattedDocumentMemoryStream = new MemoryStream();
        var formattedRadFlowDocument = htmlFormatProvider.Import(formattedContent, TimeSpan.FromSeconds(30));
        docxFormatProvider.Export(formattedRadFlowDocument, formattedDocumentMemoryStream, TimeSpan.FromSeconds(30));
        var formattedBytes = formattedDocumentMemoryStream.ToArray();
        await File.WriteAllBytesAsync(formattedDocumentSavePath, formattedBytes);
    }
}

The minified HTML produces the following document:

The formatted HTML produces the following document:

Import the following HTML content and export it to DOCX format:

            <p>Here is my list</p>
            <ol start="108" style="list-style-type: lower-latin;">
                <li>Item 1</li>
                <li>Item 2</li>
            </ol>

Expected result: 

Actual result:

Paragraphs with a bulleted "Normal" style, but with bullets removed inline, revert to showing bullets after import/export with Telerik Document Processing (DPL)—is not the intended behavior. Inline overrides, such as manually removing bullets from specific paragraphs, should be preserved after processing:

RadFlowDocumentEditor.InsertDocument throws NullReferenceException when inserting a document with incorrectly paired permission range elements.

Valid (Nested):

<w:permStart w:id="1"/>
  <w:permStart w:id="2"/>
    ... content ...
  <w:permEnd w:id="2"/>
<w:permEnd w:id="1"/>

Invalid (Overlapped):

<w:permStart w:id="1"/>
  <w:permStart w:id="2"/>
<w:permEnd w:id="1"/>
  <w:permEnd w:id="2"/>

Workaround - Remove all Permission Ranges before inserting:

var startPermissionRanges = contentDocument.EnumerateChildrenOfType<PermissionRangeStart>().ToList();
var endPermissionRanges = contentDocument.EnumerateChildrenOfType<PermissionRangeEnd>().ToList();

foreach (PermissionRangeStart rangeStart in startPermissionRanges)
{
    rangeStart.Paragraph.Inlines.Remove(rangeStart);
}

foreach (PermissionRangeEnd rangeEnd in endPermissionRanges)
{
    rangeEnd.Paragraph.Inlines.Remove(rangeEnd);
}

When the document is encoded in two-byte encoding using Little-Endian, the CsQuery HTML parser provides the entire document as FirstChild of the <body> tag, which leads to incorrect import.
This seems to be occurring with MS Outlook messages saved as HTML.

Workaround: convert the file to Big-Endian encoding before importing.

The item is closed as duplicate. Please, submit your votes and subscribe for notifications to the item at https://feedback.telerik.com/Project/184/Feedback/Details/190053-wordsprocessing-support-for-importing-dotm-dotx-and-docm-files.

Hyperlinks should support this property in order to describe where they should be opened (in the same frame/tab or in a new one). It is described in the OOXML specification as tgtFrame (Hyperlink Target Frame). It will be useful for setting the target as _blank.

When importing from HTML, all successive spaces in a spans are trimmed. Instead, in some cases one space should be left, e.g. between words. For example, the importing the following HTML should leave one space after the hyperlink:

<p><a href="www.telerik.com" target="_blank"><span>test</span></a>      and more.</p>

Workaround: After importing, check if the runs after the hyperlinks start with space:
foreach (var hyperlinkEnd in this.document.EnumerateChildrenOfType<FieldCharacter>().Where(f => f.FieldCharacterType == FieldCharacterType.End))
{
    Paragraph currentParagraph = hyperlinkEnd.Paragraph;
    int indexOfNextRun = currentParagraph.Inlines.IndexOf(hyperlinkEnd) + 1;
    if (currentParagraph.Inlines.Count > indexOfNextRun)
    {
        Run run = currentParagraph.Inlines[indexOfNextRun] as Run;
        if (run != null && run.Text[0] != ' ')
        {
            run.Text = " " + run.Text;
        }
    }
}

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.

ArgumentException with 'Invalid value' message is thrown when importing invalid font sizes from docx, e.g.

<w:sz></w:sz> 

(the 'val' attribute should be specified according to the OOXML specification).

Instead, such documents could be imported as the w:sz is not specified, similar to the behavior of MS Word.