In scenarios when center and right tabs are used for aligning the paragraph content to both left and right the text content in the exported PDF is not positioned as expected.

LineInfo objects are not cleared when there are tables in the document being exported to PDF which leads to OutOfMemoryException.

Is there a way to prevent font embedding in the RadFlow methodology or is utilizing RadFixed the only way to have a reasonably sized PDF document?

List indent is not correct when exported to PDF. All indents start from the same position.

Exception when there are merge fields in the header/footer and one performs mail merge: 

Unable to cast object of type 'Telerik.Windows.Documents.Flow.Model.Header' to type 'Telerik.Windows.Documents.Flow.Model.BlockBase

This is only reproducible when the Run contains an empty string. If the paragraph is empty or the Run contains a space, everything is working correctly.

Workaround: Remove all empty runs from the document.

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);
    }
}

When table with table border without color set is created (the color is null), and the document is exported to PDF, ArgumentNullException is thrown. 

Workaround: Explicitly set a color where the color is null.
private void PdfExport()
{
	var tables = this.document.EnumerateChildrenOfType<Table>();

	foreach (var table in tables)
	{
		TableBorders coloredClone = this.CopyTableBorders_SetColorWhenOmitted(table);
		table.Borders = coloredClone;
		
		using (Stream output = new FileStream(fileName, FileMode.OpenOrCreate))
		{
			provider.Export(this.document, output);
		}
	}
}

private TableBorders CopyTableBorders_SetColorWhenOmitted(Table table)
{
	var leftBorder = new Border(table.Borders.Left.Thickness,
				  table.Borders.Left.Style,
				  table.Borders.Left.Color ?? new ThemableColor(Colors.Transparent),
				  table.Borders.Left.Shadow,
				  table.Borders.Left.Frame,
				  table.Borders.Left.Spacing);

	var rightBorder = new Border(table.Borders.Right.Thickness,
				  table.Borders.Right.Style,
				  table.Borders.Right.Color ?? new ThemableColor(Colors.Transparent),
				  table.Borders.Right.Shadow,
				  table.Borders.Right.Frame,
				  table.Borders.Right.Spacing);

	var bottomBorder = new Border(table.Borders.Bottom.Thickness,
				table.Borders.Bottom.Style,
				table.Borders.Bottom.Color ?? new ThemableColor(Colors.Transparent),
				table.Borders.Bottom.Shadow,
				table.Borders.Bottom.Frame,
				table.Borders.Bottom.Spacing);

	var topBorder = new Border(table.Borders.Top.Thickness,
				table.Borders.Top.Style,
				table.Borders.Top.Color ?? new ThemableColor(Colors.Transparent),
				table.Borders.Top.Shadow,
				table.Borders.Top.Frame,
				table.Borders.Top.Spacing);

	var insideHorizontalBorder = new Border(table.Borders.InsideHorizontal.Thickness,
			 table.Borders.InsideHorizontal.Style,
			 table.Borders.InsideHorizontal.Color ?? new ThemableColor(Colors.Transparent),
			 table.Borders.InsideHorizontal.Shadow,
			 table.Borders.InsideHorizontal.Frame,
			 table.Borders.InsideHorizontal.Spacing);

	var insideVerticalBorder = new Border(table.Borders.InsideVertical.Thickness,
			table.Borders.InsideVertical.Style,
			table.Borders.InsideVertical.Color ?? new ThemableColor(Colors.Transparent),
			table.Borders.InsideVertical.Shadow,
			table.Borders.InsideVertical.Frame,
			table.Borders.InsideVertical.Spacing);

	var tableBorders = new TableBorders(leftBorder, topBorder, rightBorder, bottomBorder, insideHorizontalBorder, insideVerticalBorder);

	return tableBorders;
}

Style properties defined in an element style selector are evaluated with higher priority over properties in a CSS class when importing from HTML.

For example if we have the following CSS style:

.sectionheading {
border: 10px solid red;
        }
td {
border: 10px solid black;
        }
and the class (.sectionheading) is applied on a table cell:

<td class="sectionheading">...</td>

The result in WordsProcessing after import of such HTML will be that the table cell has 10px black border. In MS Word and in the browsers (Chrome, Firefox...) the result will be that the cell has 10px red border.

If the Table's TableCellSpacing property is not divided by 2 when the document is exported to Docx or Rtf, this leads to incorrect rendering after the exported document is opened with another editor (RadRichTextBox, MS Word).

Workaround: Divide by two the Table's table cell spacing property value before export to Docx, RTF formats:
foreach (Table table in document.EnumerateChildrenOfType<Table>())
{
    table.TableCellSpacing /= 2;   
}

Table's 'cellspacing' and 'cellpadding' are not imported from HTML when the unit is not specified, e.g. <table cellpadding="25">. According to the HTML Specification (https://www.w3.org/TR/REC-html40/struct/tables.html#adef-cellspacing), the only permitted values are:
- only number
- number followed by percent.

MS Word imports it according to the specification (like WordsProcessing), but all of the browsers successfully imports values even with the px suffix, e.g. '25px'.

If the background color is applied to <tr> element then it is not imported.

Workaround: The background color may be applied to the cells (<td> elements) in the desired row and this should have the same effect.

The Spacing Before property of the paragraph at the start of the page should not be respected if it is not the first one inside the current section.

Manually overriding the Spacing Before property would resolve the issue.

When the <sectPr> element is not defined as the last child element but appears in different position of the <body> of the document, the content after <sectPr> is not imported. 

Although some applications handle this case, according to the Office Open XML specification, the sectPr element must be the last element inside the <body>.