When a ToUnicode CMap is defined for Simple Font (TrueType or Type1 font) which maps font character codes to two or more Unicode character values, the extracted text should contain the whole set of characters defined in the mappings. The current implementation of RadPdfViewer takes the first character specified in the ToUnicode mapping which leads to missing characters.

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

Add built-in localization for the UI control and its tooltips. Currently they can be localized by expanding the XAML of RadPdfViewerToolBar and adding the required resources to the code.

At the moment the AnnotationsHandler, SelectionHandler and PanHandler cannot be removed or disabled. It would be convenient for this to be possible.

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.

A similar scenario is not defined in the PDF specification but the widgets can be rendered as read-only fields despite the fields associated with them are missing.

Instead, we should not visualize them and they should not be interactable with the mouse.

Fix available in LIB Version 2018.2.730.

When importing documents containing Interactive FormFields with an empty collection of Normal state appearances, a NullReferenceException is thrown, which leads to non-editable FormFields in PdfViewer.

Fix available in LIB Version 2018.2.730.

It seems that the glyph outlines are rendered wrong for some specific CFF font files. For instance, the issue is reproducible with "Aleo-Light" font.

When importing document containing a destination which points to invalid page reference, KeyNotFoundException is thrown.

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

When the Interactive Form Fields are in read-only mode, the user should not be able to change the value of the field. The associated Form Field widgets should not interact with the user, e.g. they should not respond to mouse clicks or change their appearance in response to mouse motions.

When modifying Interactive Forms TextBoxField's value the entered changes are preserved after is clicked out of the TextBoxField's editing area. However the changes are not applied when the click is performed on the save button.

As possible workaround you can raise a MouseLeftButtonDown event on the RadPdfViewer and after this execute the SaveAsCommand. For example:

private void SaveButton_Click(object sender, RoutedEventArgs e)
{
    MouseButtonEventArgs mouseEventArgs = new MouseButtonEventArgs(Mouse.PrimaryDevice, 0, MouseButton.Left)
    {
        RoutedEvent = FrameworkElement.MouseLeftButtonDownEvent
    };
 
    ((FrameworkElement)this.pdfViewer.FixedDocumentPresenter).RaiseEvent(mouseEventArgs);
    this.pdfViewer.CommandDescriptors.SaveAsCommandDescriptor.Command.Execute(null);
}

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)

...

Usually, the entries are on neighboring rows. However, some producers introduce some extra blank rows between entries and this causes exception in RadPdfViewer implementation.

Fix available in R2 2018 SP1 release version.

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);
    }
}

The width values from the widths PDF property should be taken with priority compared to the font file calculations.

Fix available in R2 2018 SP1 release version.

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

Currently the minimal zoom out value is 0.8% which impacts the performance while scrolling large documents.

This is caused by an incorrect order of applying the TextMatrix and the glyph stroking operation.