When there is no ToUnicode CMap, the text from the Simple Font instance 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. 

This is not a valid PDF scenario as having appearance state requires having multi-state appearances. However, we should handle this invalid document scenario on our side so that the app does not crash with NullReferenceException.

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.

The exception is thrown during "Put" operator execution.

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.

Hi,

The RadPdfViewer ExportPages is broken in the new release. It works in the previous version.

PdfViewer: Password protected documents cannot be opened 

Workaround:

PdfFormatProvider provider = new PdfFormatProvider();
PdfImportSettings settings = this.radPdfViewer1.PdfViewerElement.ImportSettings;
settings.UserPasswordNeeded += (s, a) =>
{
    a.Password = "1234";
};

provider.ImportSettings = settings;

this.radPdfViewer1.LoadDocument(@"..\..\password.pdf");

The viewer is using a large amount of memory when scrolling a specific PDF file. After some point, an OutOfMemeory exception is thrown.

Workaround:

Build for the x64 platform

Good morning.

I'm using a pdfViewer instance in order to load pdf forms, with text fields to be edited by the users.

Loading is ok, editing is ok, the problem is when I go to save the edited document. When I save the document, if I don't click elsewhere in the document, in which case the content of the field is committed, the content of the field is not saved with the document. This happens either using the 'Save As' button or using the SaveDocument API function.

Probably it is my fault, since I'm new to PdfViewer: I can imagine that something like a commit command has to be available, but I'm not able to find it.

Can you help me, please?
Thank you in advance.

PS. I will attach three screenshots in order to let you understand better what I mean.