This is reproducible with specific PDF files which use custom Encoding for the fonts of the field widgets. WORKAROUND: Change the font of VariableContentWidgets before editing the field value. You should additionally call RecalculateContent() method of these widgets if the value of their corresponding fields is not edited. The following method may be used for changing the font of all existing widgets in the document: private static void FixEncodingIssues(RadFixedDocument document) { foreach(Annotation annotation in document.Annotations) { VariableContentWidget widget = annotation as VariableContentWidget; if(widget != null) { widget.TextProperties.Font = FontsRepository.Helvetica; } } }
Implement the "k" and "K" color operators, which sets the color in DeviceCMYK color space. Currently graphics with color set with these operators are imported with incorrect colors. Available in R2 2018 Official Release Version.
Some PDF files have an additional content added before the file header (before %PDF-1.4 for example). This additional content makes all byte offsets in the document invalid, which causes the format provider to throw an exception. At this point, to import a similar document it should be pre-processed so the content before the version header is removed before importing it.
System.Uri constructor throws UriFormatException when the text is some http address. Available in LIB Version 2017.2.814.
According to PDF specification, the resources used for the dynamic appearance of fields are defined globally in AcroForm "DR" PDF property. However, there are some invalid documents which define these resources locally in the field node which causes exception in PdfProcessing implementation. As there are several such documents we may consider handling such scenario instead of throwing the exception. Available in R3 2017 SP1 Official Release.
According to PDF specification widget's parent field should always be terminal field and should have FieldType specified. However, there are documents which are generated without fulfulling this rule and we need to consider handling this scenario without any exceptions.
This is because PdfProcessing does not export Annotation Flags and this way all annotations has Print flag set to false. Available in Release Version R2 2017 SP1.
Allow customers to encrypt their documents using certificates.
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.