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 imported in the WordsProcessing model, the current HTML doesn't respect the defined column width and all columns have identical width:
<colgroup>
<col span="1" style="width: 33.3302%;">
<col span="1" style="width: 17.5658%;">
<col span="1" style="width: 49.104%;">
</colgroup>Observed result:
Expected result:
Workaround: use the width property as follows:
<colgroup>
<col span="1" width="33.3302%">
<col span="1" width="17.5658%">
<col span="1" width="49.104%">
</colgroup>
When importing HTML content to a RadFlowDocument and exporting it to PDF format, the following error message occurs:
System.ArgumentException: 'The document element is associated with another parent. (Parameter 'item')'
at Telerik.Windows.Documents.Fixed.Model.Collections.DocumentElementCollection`2.VerifyDocumentElementOnInsert(T item)RTF import loses the font applied once at paragraph/body level and falls back to a default font instead, when the \fonttbl uses flat, non-grouped font entries rather than individually braced {\fN ...} fonts.
Workaround: Re-save the document in MS Word.
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.