When merging, only the widgets are copied but not their fields. This can lead to ArgumentNullException when exporting the document. Implement copying the fields and consider cases which include collision of names of the fields.

Workaround:
Repair the generated document using the following code:
foreach (Widget widget in this.pdfDocument.Annotations.Where(annot => annot.Type == AnnotationType.Widget))
{
    if (!this.pdfDocument.AcroForm.FormFields.Contains(widget.Field.Name))
    {
        this.pdfDocument.AcroForm.FormFields.Add(widget.Field);
    }
}
In case of Name collision, you can use the attached project or the attached project to the following feedback item to rename the duplicate fields: Provide a way to rename FormFields.

A NullReferenceException is thrown when trying to clone the Signature property of the field.

Available in LIB Version 2018.1.312.

Trying to clone the Signature of a SignatureField leads to InvalidOperationException as the FieldName of the cloned signature is already set.
Workaround: Remove the signatures before the merging of the document:
private static void RemoveSignatures(RadFixedDocument document)
{
	List<FormField> signatures = document.AcroForm.FormFields.Where(ff => ff.FieldType == FormFieldType.Signature).ToList();
	if (signatures.Count > 0)
	{
		foreach (FormField signature in signatures)
		{
			document.AcroForm.FormFields.Remove(signature);
		}
	}

	List<SignatureWidget> signatureWidgets = document.Annotations.Where(a => a.Type == AnnotationType.Widget && a.GetType() == typeof(SignatureWidget)).Cast<SignatureWidget>().ToList();
	if (signatureWidgets.Count > 0)
	{
		foreach (var signatureWidget in signatureWidgets)
		{
			foreach (RadFixedPage page in document.Pages)
			{
				if (page.Annotations.Contains(signatureWidget))
				{
					page.Annotations.Remove(signatureWidget);
				}
			}
		}
	}
}

In business or enterprises there is more and more demand for PDF/A-3.

In Germany it is Zugferd for hybrid invoices, in Brazil Nota Fiscal Eletronica 2.0, in France FACTUR-X.

Also for longterm preservation it is import to support PDF/A-3.

If I would be the PM of this library this would be my number one priority!

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.