This is not quite a valid PDF file scenario according to PDF file specification. However, we may try handling it in order to show the correct number of pages. When the kid is of type Pages, it should be added to the pages traversal recursion only the first time it is met.

When importing a document containing a single associated widget annotation merged into the field dictionary the field is skipped on import and an exception is thrown.

According to the PDF Specification: Field Dictionaries: Kids:

An array of indirect references to the immediate children of this field.
In a non-terminal field, the Kids array is required to refer to field dictionaries that are immediate descendants of this field. In a terminal field, the Kids array ordinarily must refer to one or more separate widget annotations that are associated with this field. However, if there is only one associated widget annotation, and its contents have been merged into the field dictionary, Kids must be omitted.

A memory leak in RadPdfViewer when the control gets removed from the visual tree.

To work this around, use the reflection API to access the leaking VisualTarget objects and call their Dispose method manually.

var pdfViewer = hostBorder.Child as RadPdfViewer;

if (pdfViewer != null)
{
    var canvas = viewer.ChildrenOfType<Canvas>().FirstOrDefault(x => x.GetType().Name.Contains("ContentElementsCanvas"));                
    var visualTargetsDictionaryField = canvas.GetType().GetField("pageNumberToVisualTarget", BindingFlags.NonPublic | BindingFlags.Instance);
    var visualTargetsDictionary = (Dictionary<int, List<VisualTarget>>)visualTargetsDictionaryField.GetValue(canvas);
    foreach (KeyValuePair<int, List<VisualTarget>> target in visualTargetsDictionary)
    {
        for (int i = 0; i < target.Value.Count; i++)
        {
            VisualTarget item = target.Value[i];
            item.RootVisual = null;
            item.Dispose();
        }
    }  
}
hostBorder.Child = null;
hostBorder.Child = new RadPdfViewer() { Document = newDocument };

The issue is reproducible only on Windows XP. On newer versions of windows, the images are rendered as expected.

WORKAROUND: You may inherit DctDecode class in order to implement custom decoder. For instance, you may try calling DecodeWithJpegDecoder method from the base class as mentioned in the note of this documentation article:

http://docs.telerik.com/devtools/wpf/controls/radpdfviewer/customization-and-extensibility/customize-pdf-rendering

A sample implementation of these custom decoder may be seen below:

public class CustomDctDecode : DctDecode
{
    public override byte[] Decode(PdfObject decodedObject, byte[] inputData, DecodeParameters parms)
    {
        return DecodeWithJpegDecoder(inputData);
    }
}

Currently, the PdfProcessing document model is providing support only for a single function in the Function entry.

According to the PDF Specification: Function: A 1-in, n-out function or an array of n 1-in, 1-out functions.

As a result, the glyphs are not measured and positioned properly. The issue applies to the TrueType and Type1 fonts.

This action is usually linked to a Button field and with it, the user of the application may revert all field values to their defaults. 

Some colors are changed due to incorrect import of some graphic state colors.