Currently, a NullReferenceException is thrown because of the incorrect structure. 

As a workaround, the exception can be handled using the Handling Exceptions mechanism.

Update:
When importing documents with invalid structure of path construction operators an InvalidGraphicOperandsCountException is thrown which could be handled using the Handling Exceptions mechanism.

PdfFormatProvider provider = new PdfFormatProvider();
provider.ImportSettings.DocumentUnhandledException += this.ImportSettings_DocumentUnhandledException;

private void ImportSettings_DocumentUnhandledException(object sender, DocumentUnhandledExceptionEventArgs e)
{
    if (e.Exception is InvalidGraphicOperandsCountException)
    {
        e.Handled = true;
    }
}

When exporting a document with the .NET Framework implementation, only subsets of the used fonts are embedded in the document. 

This is currently not available in the Silverlight implementation, and it most probably won't be available in the .NET Standard implementation, as the current implementation is dependent on the WPF font classes.

Provide API to plug similar logic when using different platforms as well.
This item wil handle the TrueType OpenType Font format. For the Compact Font Format (CFF) please follow: Export subset of Compact Font Format (CFF) fonts for platforms different than .NET Framework

According to the PDF specification:
A clipping path operator (W or W*) may appear after the last path construction operator and before the path-painting operator that terminates a path object.

Invalid:

W                          % clipping path operator
0 0 m                     % start of the path construction
596 0 l
596 842 l
0 842 l
h                            % end of the path construction
n                            % path-painting operator

0 0 m
596 0 l
596 842 l
0 842 l
h
W
n

Currently (in the invalid cases), the path construction is skipped on import.

Currently, when registering *.otf font file with FontsRepository.RegisterFont method an exception is thrown during the font creation. 

WORKAROUND:  The font file may be converted to TTF format (*.ttf) which is successfully registered. This conversion may be achieved with FontForge by opening the font file and then choosing File -> Generate Fonts -> TrueType -> Generate. More information on FontForge program may be found here: https://fontforge.github.io/en-US/

PdfProcessing: Handle merge of documents containing fields with the same invalid name.

It will be possible to add an SVG element in a RadFixedPage so that it can be exported to PDF via the RadPdfProcessing library.

When exporting a document with the .NET Framework implementation, only subsets of the used fonts are embedded in the document.

RadPdfProcessing currently supports interactive forms whose data is defined directly in the document. Add support for interactive forms based on the Adobe XML Forms Architecture (XFA). The entry is defined inside the interactive forms dictionary and refers to an XML stream containing the information of the form. More information is available on page 722 from Pdf Reference, version 1.7.

ZUGFeRD (acronym for Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a specification for the electronic invoice format of the same name.

The feature depends on the following features:

• Support for embedded file streams
• Support for metadata streams (XMP metadata)

Add support for a strikethrough property or strikethrough-related properties in the TextProperties class.

They are exported with the /EmbeddedFiles switch. This would allow adding external files to the PDF document.

To bring RadPDFProcessing to the next level you should support XMP metadata. This would extremely help to use pdf files from RadPDFProcessing in digital workflows.

Reference: http://www.adobe.com/devnet/xmp.html