Loading a document that contains big images could lead to OutOfMemory exception.
We have a good news for all of you who have experienced problems with the memory consumption of RadPdfViewer. We have made significant optimization of what is cached for each page when scrolling in a document. Please have in mind that when using big images in a document the optimization may seem not so significant. This is because there is additional opportunity to further optimization of the caching mechanism for the image sources. I have logged this additional opportunity as a different feature request. Here is a link if you would like to subscribe for status updates of that item to: Optimize the image source cache - http://feedback.telerik.com/Project/143/Feedback/Details/189305-optimize-the-image-source-cache
The fix will be available in our official release Q1 2016.
When a PDF document contains images compressed with CCITTFaxDecode with applied BlackIs1 parameter, black color is visualized as white and white as black.
Printing document on a machine with .NET Framework 4.6 installed does not work for some documents. Currently, an issue is opened at Microsoft Connect: "Printing with PrintDialog fails when .NET 4.6 is installed" (https://connect.microsoft.com/VisualStudio/feedback/details/1980419/printing-with-printdialog-fails-when-net-4-6-is-installed). Workaround: In the attached project.
This is caused by an incorrect order of applying the TextMatrix and the glyph stroking operation.
Due to excessive memory consumption when decoding images, OutOfMemoryException can be thrown when viewing documents with large images inside them. Workarounds: - Set ExtensibilityManager.MaxImageSize = null. This will skip one resizing step, and could be beneficial in documents containing few large images. - Use 64-bit process for the client application. This allows the process to consume much more memory. Note that starting 64-bit process while debugging can be tricky, as described in this blog post: https://weblog.west-wind.com/posts/2016/Dec/19/Visual-Studio-Debugging-and-64-Bit-NET-Applications. Available in R1 2018 Official release version.
The images are loaded asynchronously and when scrolling too fast, the loader might fail to load an image if it is bigger.
RadPdfViewer does not read image resources defined in Form XObject elements.
This exception is thrown because there is field name with special characters which are incorrectly modified during the recalculation process of widget appearances. This exception is thrown in the internal RecalculateMissingAppearances method or in RecalculateWidgetAppearancesOld method.
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 >>
The issue is reproducible only for some specific font files. The characters are displayed as rectangles. This seems to caused by incorrect glyph name and glyph id mapping.
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.