Currently, Standard fonts are exported always with StandardEncoding. This does not allow export of some special characters which do not fit in the first 255 glyph definitions in the font. Most of these characters are the ones with an accent such as "Eacute" glyph (É) which is with position number 303 in Times Roman font. The list of all standard fonts may be found in this documentation section:
https://docs.telerik.com/devtools/document-processing/libraries/radpdfprocessing/concepts/fonts#standard-fonts

This happens only in cases when the Radio flag is not set and there are multiple widgets with different "ON" state names.

Available in R1 2018 SP2 version.

The exception is thrown with the message "Password is not correct" even when the user password is correct. This issue occurs for specific encryption algorithm parameters only.

Currently, NotSupportedEncryptionException is thrown when PdfFileSource is initialized with an encrypted PDF file.

Available in R2 2018 Official Release Version.

Currently, NotSupportedEncryptionException is thrown.

The letters are disordered after the file is exported using PdfFormatProvider.

This exception corrupts the whole document import. Instead, we should provide Exception handling mechanism which allows the user to import the rest of the content.

According to PDF specification, the field value should be specified in the "V" entry of the corresponding PDF dictionary. However, some PDF producers are skipping this entry and are setting only the Widgets appearance states. As most viewers manage to show the radio button and checkbox as selected, we should handle this scenario and import the field values based on the related widgets when this value is not explicitly set with the field's V entry.

Implement importing and exporting the javascript actions associated with push button fields so that they can be executed when the exported document is opened with Adobe Acrobat. Javascript actions are also used by text fields for text validation (for instance for date input).

Current implementation relies on valid cross-reference offsets in the PDF documents so that PDF objects are easily found and parsed. However, we can implement a mechanism for repairing documents with invalid cross-reference tables.

The attached project shows how to repair the simplest case of cross-reference table by using RepairDocumentWithSimpleCrossReferenceTable method.

If a PDF with a TextBoxField is created with a corresponding Widget, the text is actually long enough to be broken in more than one line and AllowScroll is set to true, upon opening the file in Adobe, the text is not visible. The field actually does have an appearance which can be seen upon inspection of the document but for some reason it is not visualized.

Another issue seems to be a different manifestation of the same problem: When the text is long and AllowScroll is false, the text will be visible, but will be misplaced. The issue is caused by the length of the text because the same field with a shorter text that can fit in the widget's rectangle will be displayed correctly. 

This operator is used for drawing shading patterns.

InvalidOperationException is thrown when exporting font that is available but not used.

The stack trace is as follows:
   at System.Linq.Enumerable.Max(IEnumerable`1 source)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.Cid.CidSet.CopyPropertiesFrom(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontDescriptor.CalculateCidSet(IPdfExportContext context, CidFontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontDescriptor.<>c__DisplayClass34.<CopyPropertiesFrom>b__30()
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Utilities.PdfObjectsExtensions.ToPrimitive[P,T](PdfProperty`1 pdfProperty, Func`2 convertToPrimitive, Func`1 getDefaultValue)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontDescriptor.CopyPropertiesFrom(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontObject.CopyPropertiesFromOverride(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontObject.CopyPropertiesFrom(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.Type0FontObject.CopyPropertiesFromOverride(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Export.PdfExporter.WriteFontsFromContext(PdfWriter writer, IPdfExportContext context)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Export.PdfExporter.Export(IRadFixedDocumentExportContext context, Stream output)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.PdfFormatProvider.ExportOverride(RadFixedDocument document, Stream output)
   at Telerik.Windows.Documents.Common.FormatProviders.FormatProviderBase`1.Export(T document, Stream output)

The field name should be preserved on an import-export scenario. However, in some cases when the field name contains non-ASCII characters then the field name is exported with different value compared to the imported one.

Fix available in LIB Version 2017.3.1009.

Currently, there is no way to know when a new page is created when content "overflows" to the next page 

This event may be needed in order to generate the header and footer based on the currently generated content. In simple header/footer scenarios, however, this event may not be needed and the headers and footers may be drawn after all pages are generated as described in the comments below.

The CropBox is currently not supported by RadFixedPage class and is not preserved on an Import-Export scenario with PdfFormatProvider. CropBox is also not supported by PdfPageSource class and it is not preserved by using PdfStreamWriter as well. This property should be implemented in both scenarios.

Implement the Exponential Interpolation Function in PdfProcessing. Currently, NotSupportedFunctionTypeException is thrown with a message "Function type 2 is not supported."

Implement Viewer related properties in PdfProcessing in order to enable the users to set PrintScaling, Duplex, and other properties which are written in the Pdf Format specification as Interactive Features. 

ViewerPreferences are written a document's catalog. Check p.577 from pdf reference format specification, version 1.7

PDF/A-1a is with conformance level A (for "accessibility"), and must adhere to all of the requirements of the PDF Reference as modified by the ISO 19005 specification. 

It requires structural and semantic properties to be preserved. Level 1a uses “Tagged PDF” and Unicode character maps to preserve the document's logical structure and content text stream in natural reading order. 

The following features are used:
- Language specification
- Hierarchical document structure
- Tagged text spans and descriptive text for images and symbols
- Character mappings to Unicode

The purpose is to improve accessibility and make the content accessible for screen readers.

For complienace level PDF/A-2a please follow: PdfProcessing: Add support for PDF/A-2a compliance level.

The currently supported compliance levels can be found in the How to Comply with PDF/A Standard article.

The PDF format includes a general multimedia framework allowing users to insert and play/visualize different media types. The feature is described on page 755 from PDF Reference 1.7.