Please refer to the attached sample screenshot demonstrating how the document look in Adobe and in RadPdfViewer.

Currently, RadPdfViewer uses WPF DrawingContext class for drawing page elements to a Canvas.  When PDF page has many content elements (usually geometries) drawing the page may be time-consuming and freezes the UI. 

Instead, we should consider implementing another approach for rendering the content asynchronously which would improve the user experience. 

Some files when opened with PdfViewer will throw a KeyNotFoundException which will be handled. Parts of the text in the file might or might not be missing.

When the file has an annotation with a destination and this destination is missing from the destinations (Dests) collection of the catalogue, KeyNotFoundException is thrown when you try to scroll to the page where the annotation is located. A better behavior would be for nothing to happen when trying to click on the annotation leading to the destination.

structure
The hierarchical document structure is a means to describe the PDF document structure, which is currently not supported. See 10.6.1 Structure Hierarchy on 856 page of the PDF specification for details.
This document structure is an alternative to the standard PDF structure and most non-Adobe software does not support it.

The document might have been created with Adobe software like Adobe LiveCycle Designer. Very often the document contains some fallback text in the standard PDF structure like:
"Please wait... If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document."
"The document you are trying to load requires Adobe Reader 8 or higher. You may not have the Adobe Reader installed or your viewing environment may not be properly configured to use Adobe Reader. For information on how to install Adobe Reader and configure your viewing environment please see  http://www.adobe.com/go/pdf_forms_configure."
"For the best experience, open this PDF portfolio in Acrobat X, Reader X, or later."

When there is no ToUnicode CMap, the text from the Simple Font instance (TrueType or Type1 font) should be extracted by mapping the glyph name to its corresponding charcode according to Adobe Glyph List. Additionally, the Differences array should be included in these calculations when there is custom encoding. The current implementation of RadPdfViewer makes ToString to the original char id byte value which leads to wrong characters. 

More information about this may be seen in the second point of section "5.9.1Mapping Character Codes to Unicode Values" on page 470 in PdfReference 1.7.

The rendering of images with size ~5000/6000 and BitsPerComponent is time-consuming. The scenario is optimized in terms of memory but would be nice to increase the performance as well.

This is Unicode (UTF-16BE) encoding for the Adobe-GB1 character collection; contains mappings for all characters in the GB18030-2000 character set.

Described on page 443 in Pdf Reference 1.7.

RadPdfViewer partially supports CCITTFaxDecode (that is basically TIFF). There are some limitations that are not supported at this stage like EncodedByteAlign = true or Group 3, 2-D encoding.

When Find Next is used multiple times fast, and pages are still loaded asynchronously, sometimes NullReferenceException is thrown with the following call stack:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Telerik.Windows.Documents.Fixed.Text.TextRecognizer.GetLastCharacter()
   at Telerik.Windows.Documents.Fixed.Text.TextRecognizer.IsLineBreak(Glyph glyph)
   at Telerik.Windows.Documents.Fixed.Text.TextRecognizer.ProcessGlyph(Glyph glyph)
   at Telerik.Windows.Documents.Fixed.Text.TextRecognizer.CreateTextPage(RadFixedPageInternal page)
   at Telerik.Windows.Documents.Fixed.Text.TextDocument.GetTextPage(Int32 index)
   at Telerik.Windows.Documents.Fixed.Search.KMPTextSearch.FindNext(TextDocument document, TextPosition startPosition, String searchText, Boolean matchCase, Boolean wholeWordsOnly)
   at Telerik.Windows.Documents.Fixed.Search.TextSearch.Find(String text, TextSearchOptions options)

...

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

WORKAROUND: You may try implementing custom filter that handles the CMYK scenario. How to implement custom DCTDecode filter is described in this documentation article:
https://docs.telerik.com/devtools/winforms/pdfviewer/customize-and-extensibility/customize-pdf-rendering

This is reproducible for images with FlateDecode and predictor value in the range between 10 and 15. As an example you may take a look at the DecodeParms property in the following image PDF dictionary:

<< /BitsPerComponent 8 /ColorSpace /DeviceRGB /DecodeParms << /BitsPerComponent 8 /Colors 3 /Columns 1024 /Predictor 15 >> /Filter /FlateDecode /Height 2868 /Subtype /Image /Type /XObject /Width 1024 /Length 1236707 >>

To reproduce:
Open a document that has highlighted areas.

One should be able to handle the annotations/hyperlinks clicking. 

While the other annotations are drawn on top of the content, the highlight annotation is behind the text it highlights. In other words, it has to be inserted at a specific place in the ContentElementsUILayer. The pdf seems to mark the precise place where the highlight should be placed with the BDC, MCID and EMC operators in the content. At the moment, the read-only rendering of the highlight annotation has been implemented with an instance of the AnnotationUILayer called "HighlightUILayer" which is placed behind the ContentElementsUILayer. With this implementation, depending on the contents of the pdf, the highlight annotation might be visible or it might not be. 

To reproduce:
- Drop a RadPdfViewer on a blank form at design time. 

Some documents reqire this assembly as well. 

This exception seems to be related to AES algorithm PaddingMode property.