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 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.
Currently, all images are decoded and preserved in RGBA format (32 bits for each pixel). However, there are files that optimize their images by preserving them with 1 bit for each pixel. In WPF we may create monochrome System.Windows.Media.ImageSource that would optimize the performance and memory consumption when rendering such images. Available in R1 2018 Official Release Version.
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 >>
There is opportunity to further optimize the caching mechanism of the image sources, which will reduce the memory consumption. The fast scrolling in a document containing big images could lead to an OutOfMemoryException. Available in R1 2017 Official Release Version.
Add support for Lab color space. Currently alternate color is used to render the pixels, which may result in incorrect colors.
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 exception seems to be related to AES algorithm PaddingMode property.
This happens only in scenarios when the widget has On state appearance defined and Off state appearance missing. If both appearances are missing then RadPdfViewer recalculates the appearances and the checkbox is successfully selected and deselected.
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); }
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 using SaveAsCommandDescriptor of RadPdfViewer and trying to replace a pdf file that is currently open in adobe reader causes the following exception:
System.IO.IOException: The process can not access file "C:\Temp\test.pdf" because it used by another process.