These file formats are very similar to DOCX, and can be easily imported with loss of some information (e.g. macros).
foreach
(var section
in
this
.document.Sections)
{
bool
shouldInsert =
false
;
foreach
(var block
in
section.Blocks.ToList())
{
var paragraph = block
as
Paragraph;
if
(paragraph !=
null
&& paragraph.ListId > -1)
{
shouldInsert =
true
;
}
else
if
(shouldInsert)
{
var paragraphToInsert =
new
Paragraph(
this
.document);
paragraphToInsert.Spacing.LineSpacing = 1;
paragraphToInsert.Spacing.LineSpacingType = HeightType.Exact;
paragraphToInsert.Spacing.SpacingAfter = 0;
block.BlockContainer.Blocks.Insert(section.Blocks.IndexOf(block), paragraphToInsert);
shouldInsert =
false
;
}
}
}
The calculations are wrong, leading to single lines on a page. As a result, the content of the PDF document is laid out on a bigger number of pages.
Workaround: Change the line spacing and its type before exporting to PDF:
foreach (var paragraph in this.document.EnumerateChildrenOfType<Paragraph>())
{
HeightType? heightType = paragraph.Properties.LineSpacingType.GetActualValue();
if (heightType == HeightType.Exact || heightType == HeightType.AtLeast)
{
paragraph.Properties.LineSpacingType.LocalValue = Telerik.Windows.Documents.Flow.Model.Styles.HeightType.Auto;
paragraph.Properties.LineSpacing.LocalValue = 2;
}
}
In a DOCX document, the users can define an image which is bigger than the size of the page. When such an image is at the beginning of the document and is converted with PdfFormatProvider, an additional page is added in the result PDF.
foreach (var image in document.EnumerateChildrenOfType<ImageInline>()) { var section = image.Paragraph.Parent as Section; if (image.Image.Height > section.PageSize.Height - section.PageMargins.Top - section.PageMargins.Bottom) { var height = section.PageSize.Height - section.PageMargins.Top - section.PageMargins.Bottom - (image.Paragraph.Spacing.SpacingAfter * (image.Paragraph.Spacing.LineSpacing - 0.97)); image.Image.Size = new System.Windows.Size(image.Image.Width, height); } }
Add support for INCLUDEPICTURE fields. Such fields should work with nested MERGEFIELD, as this is common scenario. Workaround: Manually insert images over specific placeholderRadFlowDocument document =
new
RadFlowDocument();
RadFlowDocumentEditor editor =
new
RadFlowDocumentEditor(document);
editor.InsertText(
"1"
);
editor.InsertText(
"EXAMPLE_IMAGE"
);
editor.InsertText(
"2"
);
foreach
(var run
in
editor.Document.EnumerateChildrenOfType<Run>().ToArray())
{
if
(run.Text ==
"EXAMPLE_IMAGE"
)
{
Paragraph paragraph = run.Paragraph;
int
indexOfCurrentRun = paragraph.Inlines.IndexOf(run);
paragraph.Inlines.RemoveAt(indexOfCurrentRun);
ImageInline imageInline =
new
ImageInline(document);
imageInline.Image.ImageSource = newTelerik.Windows.Documents.Media.ImageSource(imageData,
"png"
);
paragraph.Inlines.Insert(indexOfCurrentRun, imageInline);
}
}
When MergeField is present in the document, and this merge field is evaluated to an empty string - this, for example, happens when the property in the data source is set to null, empty string, or is missing at all - the result fragment remains in the result document. Instead, it should be removed. Steps to reproduce: - Create document with merge field, the field should contain result fragment, and set data source which contains null or string.Empty value for the field: RadFlowDocument document = new RadFlowDocument(); RadFlowDocumentEditor editor = new RadFlowDocumentEditor(document); editor.InsertField("MERGEFIELD FirstName ", "Ā«FirstNameĀ»"); List<Person> source = new List<Person>() { new Person() { FirstName = string.Empty } }; RadFlowDocument mergedDocument = document.MailMerge(source); Expected: The result document is empty. Actual: The result document contains "Ā«FirstNameĀ»" string. Available in LIB Version 2017.3.1120.
Allow to password-protect a document, so that it cannot be shown (read) without the password. Also, enable opening encrypted documents.
The properties applied to the paragraph marker are not respected when evaluating the style of the child elements. That leads to exporting the bullets in a list with their default settings when they are applied to the paragraph properties. The issue is reproducible when exporting to PDF and RTF. Workaround, applicable when the style of all the bullets in the specific list is the same: Change the style of the list level:foreach
(var paragraph
in
this
.document.EnumerateChildrenOfType<Paragraph>())
{
if
(paragraph.ListId > -1)
{
this
.document.Lists.GetList(paragraph.ListId).Levels[paragraph.ListLevel].CharacterProperties.CopyPropertiesFrom(paragraph.Properties.ParagraphMarkerProperties);
}
}
When inserting content in an empty paragraph, the styles applied to it are the default document styles. However, if the properties are present in the last paragraph symbol, the content should inherit them.
Workaround: Copy the properties of the marker after inserting the content:
run.Properties.CopyPropertiesFrom(paragraph.Properties.ParagraphMarkerProperties);
This element specifies the settings for the document grid, which enables precise layout of full-width East Asian language characters within a document by specifying the desired number of characters per line and lines per page for all East Asian text content in this section.
If Latin text is interspersed on this line, then it is placed across the number of grid units needed to fit the
content, but all other grid positions are unaffected.
When a HTML has a wrong encoding set (content="text/html; charset=utf-16") we use the UTF-16 encoding when importing this HTML. This leads to wrong import. Microsoft Word detects that the set encoding is wrong and uses UTF-8 instead so that the imported result is correct. The HTML5 specification forbids the use of the meta element to declare UTF-16, because the values must be ASCII-compatible: https://www.w3.org/International/questions/qa-html-encoding-declarations#utf16