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.

TableRow which has defined an only val attribute of the trHeight is imported as a row with auto height. By the specification, this is right, but MS Word takes the val value as row height. Also MS Word exports "At Least" row height with only 'val' set.

Workaround: Iterate through the table rows and set them HeightType to Exact or AtLeast:

foreach (var row in this.document.EnumerateChildrenOfType<TableRow>())
{
    row.Height = new TableRowHeight(HeightType.AtLeast, row.Height.Value);
}

Table and table cell borders are not evaluated according to inheritance and conflict resolution rules. A conflict will occur when different borders from the table and table cell are overlapping. 

The GetActualValue method of the TableBorders and TableCellBorders could potentially return an incorrect value in some of the following scenarios:

Scenario 1:
A table has cell spacing set to 0. Meaning that the table and table cell borders will overlap.
The table borders have defined all of its borders with border style "Single".
The table cell borders have all of its borders defined with border style "None".

Expected result: the resulting borders should have the border style set to "None" for the location where the table and the cell borders are overlapping.

Scenario 2:
A table has explicitly defined that its right border is with border style "None".
The table has a table style applied with defined border style of type "Single" for all table borders.

Expected result: All of the table borders except the right border should have border style of "Single".

The problem is mostly visible when exporting to PDF and RTF format.

In the document produced by the mail merge, the date time and numeric formatting applied are not respected and the value is in its default format. 

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

The current implementation uses System.Windows.Media.Imaging.BitmapImage class in order to take the image pixels for the PDF export. However, BitmapImage class throws NotSupportedException when being initialized with a WMF or EMF image.

WORKAROUND: WMF and EMF images may be converted to PNG images before the PDF export. The following code snippet shows how to convert all inline WMF image to PNG images by using System.Drawing.Image class:

private static void ConvertInlineWmfImagesToPng(RadFlowDocument document)
{
    foreach (ImageInline image in document.EnumerateChildrenOfType<ImageInline>())
    {
        if (image.Image.ImageSource.Extension.Equals("wmf", StringComparison.InvariantCultureIgnoreCase))
        {
            using (MemoryStream wmfImageStream = new MemoryStream(image.Image.ImageSource.Data))
            {
                using (MemoryStream pngImageStream = new MemoryStream())
                {
                    var imageDrawing = System.Drawing.Image.FromStream(wmfImageStream);
                    imageDrawing.Save(pngImageStream, ImageFormat.Png);
                    byte[] pngBytes = pngImageStream.ToArray();
 
                    image.Image.ImageSource = new ImageSource(pngBytes, "png");
                }
            }
        }
    }
}

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?

The issue is observed with tables that have a specific width (in inches or percents) but whose columns do not have width specified. MS Word renders such tables expanded to their full width. For tables with 100% width, they have to expand to the entire width of the page. The same behavior is expected in the PDF export.

As a common side effect, when specific text alignment (e.g. center or right) is applied to a paragraph within a table cell, and the table is with specified width, but the column is auto-sized (without set width), then the text alignment seems as not respected. Actually the problem is that the column table is shrunk to the text width.

Workaround: this may be used before exporting the RadFlowDocument instance to PDF:

foreach (Table table in document.EnumerateChildrenOfType<Table>())
{
    table.LayoutType = TableLayoutType.FixedWidth;
}


Workaround 2:

Set specific width to the auto-sized columns (to any of the cells in the columns):

cell.PreferredWidth = new Telerik.Windows.Documents.Flow.Model.Styles.TableWidthUnit(500);

Available in R1 2018 SP2 release version.

When the last element in a table cell is an empty paragraph, the latter is skipped and not imported. It should be imported even if it's the only paragraph in the cell, as its properties could affect the layout and presentation (borders, colors, spacings).

When table row is empty, it's exported to PDF with incorrect height - depending on the type of height set with 0 or with the height of an empty paragraph.

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

An ArgumentException is thrown when importing HTML containing standard and non-standard pseudo classes or pseudo elements. The concreete scenario is the following: 
.myclass::-webkit-scrollbar or .myclass::-ms-expand

The message of the exception is similar to this: "Unexpected character found at position [X]: ".. scrollbar::>>-<<webkit-scrollbar"". 

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>.