The issue may be reproduced by opening the attached PDF in Adobe Reader. Although the viewer initially shows the characters correctly, when you start typing in the TextBox, the umlaut/diacritics characters get corrupted. In other PDF viewers, the umlaut characters are handled correctly, so the issue seems to related to concrete Adobe Reader encoding handling implementation. The diacritic characters are handled incorrectly in other viewers as well (e.g. Chrome).
The current implementation expects the widths to be integer values and InvalidCastException is thrown when a real number is parsed. Workaround: If the scenario allows, the PdfStreamWriter may be used instead of PdfFormatProvider. More information may be found in the following documentation article: http://docs.telerik.com/devtools/document-processing/libraries/radpdfprocessing/formats-and-conversion/pdf/pdfstreamwriter/overview Available in LIB Version 2017.2.731.
This is causing issues when exporting the document to PDF from WordsProcessing - the pdf library tries to create the font, but cannot find it due to a different casing. When importing HTML document, the font-family property is read with small letters. Later, when converting the string containing the value, it is changed to title case. This issue will be reproducible with each font containing a name with a letter with casing different than the one of the other letters (exc. first capital letter), for example: Microsoft JhengHei
Currently, only images without transparency may be created with this class. Available in LIB version 2017.1.410.
If the MatrixPosition has Matrix (1, 0, 0, 1, 20, 10) the Table should be positioned with top-left coordinate (20, 10). Instead, it is wrongly positioned at (40, 20).
This type of destinations is not supported and leads to InvalidCastException when importing such elements.
The current implementation of IDisposable implements a simple Dispose method which releases the inner stream resource. However, if the PdfStreamWriter instance is not disposed explicitly by calling Dispose() or by surrounding it in "using" clause, then the inner Stream resource is not Disposed as well. The same applies for PdfFileSource class. We should implement the IDisposable pattern in a way that the GC disposes the inner stream if needed when collecting the PdfStreamWriter/PdfFileSource class instances.
This leads to keeping a lot of memory when exporting pages from multiple PdfFileSource instances which are created from MemoryStream. Available in LIB version: 2017.1.320
Currently, when writing RadFixedPage the page instance reference is cached, as well as its content resources (images and fonts). This cache is important as it allows to reuse pages, images and fonts without writing them multiple times in the result PDF document. However, it needs to be optimized in order to consume less memory. The attached demo shows how to create 2500 pages with big images (different image on each page). With the current version, this demo consumes about 3 GB memory which may lead to OutOfMemoryException. With the optimization that will be introduced in LIB version, the same demo will consume about 20 MB memory for writing this big PDF document. Available in LIB version: 2017.1.320
Currently, PdfStreamWriter writes only PDF pages. If we implement API for merging multiple pages or whole documents we would be able to preserve links between pages (which are currently being corrupted). Merging whole documents would also allow preserving document properties (bookmarks, interactive forms, ...). For a more detailed list of the unsupported document properties you can refer to our documentation: https://docs.telerik.com/devtools/document-processing/libraries/radpdfprocessing/formats-and-conversion/pdf/pdfstreamwriter/features. We may also implement API for adding initial document properties from some existing PDF file.
This would ensure preserving the existing PDF file pages and document properties untouched and additionally would allow making a few modifications to the file. By appending bytes to existing PDF file one may achieve: - Modifying specific pages content and properties. - Adding new pages to pages collection. - Modify some document properties (such as Bookmarks). - Edit interactive forms field values. - Add digital signatures to existing documents.
When opened in Adobe Reader it says that the file "claims compliance". However, when verifying the compliance with some validation tools there seem to be some issues mainly related but not limited to fonts.
Matte color is used for preblending images with some background color, using the SMask. Matte color is specified using the optional 'Matte' entry for the SMask object. See PDF 1.7 specification, page 554-555: Matte array (Optional; PDF 1.4) An array of component values specifying the matte color with which the image data in the parent image has been preblended. The array consists of nnumbers, where n is the number of components in the color space specified by the ColorSpace entry in the parent image’s image dictionary; the numbers must be valid color components in that color space. If this entry is absent, the image data is not preblended.
The public API may be implemented as property of PdfExportSettings. Implementing this feature would help to easily workaround issue with PdfProcessing documents that cannot be opened on devices with iOS version 10.2 (due to the default FlateDecode compression).
For example, when some PDF file has uncompressed contents we may import it and apply better compression to the stream objects. Ensure that all the content inside the document is compressed.
Currently, we have the following options for PDF export optimizations:
pdfFormatProvider.ExportSettings.ImageQuality = ImageQuality.Low;
pdfFormatProvider.ExportSettings.ImageCompression = new ImageFilterTypes[] { ImageFilterTypes.FlateDecode };pdfFormatProvider.ExportSettings.StreamCompression = new StreamFilterTypes[] { StreamFilterTypes.FlateDecode };pdfFormatProvider.ExportSettings.FontEmbeddingType = FontEmbeddingType.Subset;
This is happening when the pages in the document has content arrays similar to the following: [34 0 R 243 0 R] [34 0 R 245 0 R] [34 0 R 247 0 R] .... As you may notice the content stream 34 0 R is reused and the issue is caused by incorrect caching of content stream indirect objects by their reference.
Currently this exception crashes the whole PDF document import. Instead we should simply skip the unsupported Action and import the rest of the PDF content correctly.
These images are defined directly in the PDF page content stream with BI and EI operators. Currently InvalidCastException is thrown when document with such images is imported. Available in R1 2018 SP2 release version.
For example exporting the text "\uD83D\uDE0A" with "Segoe UI Symbol" font family should export a single smiling face. Instead the characters are skipped during the export as PdfProcessing is trying to export them as separate char values ("\uD83D" and "\uDE0A") and the font does not contain glyphs corresponding to these char codes.
When creating a GradientStop, an alpha channel of the color could be applied. However, this setting is not respected it the result document and the gradient is with full opacity. Steps to reproduce: 1. Create a gradient with an alpha channel: RadFixedDocument document = new RadFixedDocument(); RadFixedPage page = document.Pages.AddPage(); FixedContentEditor containerEditor = new FixedContentEditor(page); LinearGradient linearGradient = new LinearGradient(new Point(0, 0), new Point(30, 30)); linearGradient.GradientStops.Add(new GradientStop(new RgbColor(10, 0, 207, 0), 0)); linearGradient.GradientStops.Add(new GradientStop(new RgbColor(10, 0, 102, 204), 1)); containerEditor.GraphicProperties.FillColor = linearGradient; containerEditor.DrawRectangle(new Rect(10, 10, 48, 29)); 2. Export the document to PDF Observed: The alpha channel is not respected and the gradient is with full opacity