There is a similar question in FAQ for FontForge (https://fontforge.github.io/faq.html#mingliu) where it is described that kaiu.ttf (and probably mingliu.ttf) font does not store the correct outlines and its outlines need special treatment in order to be rendered correctly. The Chinese glyphs are rendered wrong in RadPdfViewer as well. However, Adobe Reader, FoxitReader and ChromeViewer render the glyphs correctly.

The issue is caused by memory optimization that requires loading page content only for the visible pages. 

In order to fix the issue and still benefit from the memory optimization, we are introducing setter in FixedDocumentPresenterBase VisiblePages property. Now this property needs to be set each time the visible pages are changing in custom presenter implementation. Setting VisiblePages ensures that all visible pages content will be loaded correctly.

Even small documents (~30 kb) containing images encoded with CCITTFaxDecode filter can take about 10 seconds to be opened. In 2014 Q1 SP1 such documents load faster.

Implement import and export of content with Type0Font with GBK-EUC-H encoding.

"Save As" is common functionality in most of the popular PDF Viewers. It should save the currently loaded document to a file.

Workaround: Currently there is SDK demonstrating how to add such functionality: https://github.com/telerik/xaml-sdk/tree/master/PdfViewer/PdfViewerCustomSaveCommand

Available in R3 2017 Official Release Version.

Currently, when we parse inline image dictionaries we rely on the assumption that the colorspace will be PdfName. However, there are files with complex colorspaces that are PdfArray and InvalidCastException is thrown. All the content after this exception is lost and not visualized by RadPdfViewer.

When graphic state uses stroking text rendering mode, the glyphs are visualized with bigger stroke thickness than the expected one.

Available in LIB Version 2018.2.521.

The exception is thrown during "Put" operator execution.

This allows specifying a soft mask in the external graphics state.

When text is exported from PDF document using the TextFormatProvider (it's also used internally for the Copy operation), it is automatically split to lines using the vertical position of the words on the page, and small tolerance. 

Currently the tolerance is hard-coded to 0.1 pixels, which is not suitable for documents which contains scanned and OCR-ed text, and there the text lines could be slightly inclined. The result is that words on one slightly inclined line are recognized as if they are on separate lines.

Default DctDecode implementation uses System.Windows.Media.Imaging.BitmapImage in order to get the image pixels. However, when the image uses some complex colorspace (for instance Separation based on CMYK) the BitmapImage is initialized with a different format and we use System.Windows.Media.Imaging.FormatConvertedBitmap in order to get the pixels in CMYK colorspace. There seems to be some issue with these calculations as the resulting image has incorrect pixels.

WORKAROUND: You may inherit DctDecode class in order to implement custom decoder and call 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);
    }
}

Introduce support for Line Annotation.

Introduce support for Square Annotation

Introduce support for Circle Annotation

Introduce support for Polygon Annotation

Introduce support for PolyLine Annotation

FixedDocumentSinglePagePresenter uses simple rendering mechanism using UIElements, which currently has some limitations:
- Layers are not supported, thus annotations and forms are not rendered (even read-only)
- UIElements could be affected (clipped) when UseLayoutRounding property set at parent level, when DPI is different that 96 DPI. 

Workaround: If content is clipped, ensure that UseLayoutRounding is set to false as presenter level:
<telerikUI:FixedDocumentSinglePagePresenter UseLayoutRounding="False" />

When a page is rotated its annotations are not positioned correctly. 

Currently, the Find() method searches from the beginning of the document to its end. Enable the customer to specify a particular range of pages the method should search through.

Before starting to decode big image, try to estimate the needed memory and check if such memory is available using the MemoryFailPoint class. The behavior in case of failure in printing scenarios should be considered carefully.
The user should be able to turn the behavior on and off.