Some field values are initially not visible when opening file exported with RadPdfProcessing in Adobe Reader. The field value becomes visible once you click (focus) the field in Adobe Reader. The setting which causes this UI rendering issue may be found in "Edit" -> "Preferences" -> "Forms" -> "Highlight Color" -> "Show border hover color for fields". On the attached screenshots you may compare the rendering result when this setting is On and when it is Off.

Fix available in LIB Version 2017.2.710.

This API should provide a method for removing all fields and widgets in the document and draw the default widget appearance in place of the removed widgets.

WORKAROUND: Sample implementation for flattening form fields may be seen in the FlattenFormFields method from the attached demo project.

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.