While all the pages and components of the control are rendered on the image, the content is completely missing from it. The issue is a regression caused by the migration of the model and its async rendering introduced in R3 2020.

Workaround: Fallback to the old rendering engine:

• Changing the default behavior:

 this.pdfViewer.DefaultImportSettings.UseOldRendering = true;

• Setting the property to the format provider used to show the document:

PdfImportSettings settings = PdfImportSettings.ReadOnDemand;
settings.UseOldRendering = true;

When using CTRL+Mousewheel to zoom in to a PDFViewer document, it should zoom into the point where the mouse pointer is located. Currently it just does a simple zoom of the whole document.

For example see Acrobat Reader or Google Maps.

Handle import of documents containing Simple fonts with names of entries in the Encoding`s Differences that are not part of the Adobe Glyph List.

According to the PDF Specification (9.10.2 Mapping Character Codes to Unicode Values) if the name is not part of the list: If these methods fail to produce a Unicode value, there is no way to determine what the character code represents.

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.

There are missing characters when importing documents containing Standard fonts with a Differences array defined in the Encoding, which contains characters that do not fit in the first 255 glyph definitions in the font. Most of these characters are the ones with an accent such as "ccaron" (č).

RadPdfViewer can not find startxref keyword at the end of a document if the document contains many zero bytes at its end. NotSupportedException is thrown with "Startxref keyword cannot be found" message. 

Workaround: Trim the ending zero bytes before loading the document to the PdfViewer. This is currently noted in the WinForms KB article:
http://www.telerik.com/support/kb/winforms/details/notsupportedexception-startxref-keyword-cannot-be-found-when-loading-pdf-file-in-radpdfviewer-for-winforms

The object definitions are split into several lines:

From the PDF specification:

Prev: (Present only if the file has more than one cross-reference section; must not be an indirect reference) The byte offset from the beginning of the file to the beginning of the previous cross-reference section. 

When importing such a document an exception is thrown: System.ArgumentNullException: 'Value cannot be null.