At this point, the Print() method allowing the customers to silently print a document uses the PrintableAreaWidth and PrintableAreaHeight properties of the print dialog, which are read-only and cannot be changed through the API. Consider changing them with PrintTicket.PageMediaSize. We should also consider the scenario when the client needs to print a smaller PDF page on a bigger page size. For instance, A5 page to be printed on an A4 sheet without scaling the content.
Currently, RadPdfViewer uses default constant value for the font size in this scenario.
Most PDF viewers have option (enabled by default) which allows fields to be highlighted with colors predefined in the settings. Required fields are highlighted using different color. For example: In Adobe Acrobat Reader DC this is enabled in "Edit" -> "Preferences" -> "Forms" -> "Highlight Color" -> "Show border hover color for fields".
Expose a button in the UI that can be used instead of Ctrl+F. Such a button can be currently added by customizing the default toolbar. For more information, check the documentation that describes how to achieve that: https://docs.telerik.com/devtools/wpf/controls/radpdfviewer/default-ui#customizing-the-default-ui
At the moment the theme of the RadPdfViewerToolBar can be set only by setting the theme of the entire application. The individual setting (using telerik:StyleManager.Theme="Windows8") should also be supported.
Layers represent groups of optional content which can be hidden or shown.
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.
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.
In Adobe and Foxit readers, the user can draw different shapes, which are later saved as images in the document.
When users do "copy" operation, add the content to the clipboard in RTF format. This would allow to paste the text along with its formatting in text editors like MS Word.
They are used by the page and the XObjects drawn on it and deal with the overlaying of the colors. These groups are described on page 556 of PdfReference 1.7.
The redaction annotation is described in the following PDF reference document: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_addendum_redaction.pdf You may also see sample document with this annotation type attached. Since LIB Version 2017.3.925 annotations of type Redact can be visualized.
The document will be imported with a loss of content. The reason is that ASCII85Decoder will throw an ArgumentException when the stream doesn't end with '~>'. Although this is invalid case according to PDF specification, other applications are handling it and the document is successfully visualized in them. We may also consider implementing workaround that handles such invalid streams.
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.