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. 

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.

For example exporting the text "\uD83D\uDE0A" with "Segoe UI Symbol" font family should export a single smiling face. Instead the characters are skipped during the export as PdfProcessing is trying to export them as separate char values ("\uD83D" and "\uDE0A") and the font does not contain glyphs corresponding to these char codes.

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;
        }
    }
}

CryptographicException is thrown when saving with PdfStreamWriter or importing with PdfFormatProvider.

The exception: System.Security.Cryptography.CryptographicException: 'The input data is not a complete block.'

When characters are in the ranges 61472-61566, 61565-61695, 65535-65535 they are correctly exported with Wingdings font. However, when the character value is outside these ranges the font fallback mechanism exports them with different font and this causes wrong glyph rendering in the resulted PDF.

The following code snippet shows how the Wingdings characters can be modified so that they are correctly exported to PDF when converting from WordsProcessing's RadFlowDocument:
RadFlowDocument document = new DocxFormatProvider().Import(File.ReadAllBytes(@"test_document.docx"));
foreach (Run run in document.EnumerateChildrenOfType<Run>())
{
    if (run.FontFamily.GetActualValue(document.Theme).Source.Contains("Wingdings"))
    {
        StringBuilder modifiedText = new StringBuilder();

        foreach (char character in run.Text)
        {
            modifiedText.Append(character > 256 ? character : (char)(character + 61440));
        }

        run.Text = modifiedText.ToString();
    }
}
Workaround: When creating a RadFixedDocument:
using (RadFixedDocumentEditor editor = new RadFixedDocumentEditor(this.fixedDocument))
{
	byte[] data = File.ReadAllBytes(@"CustomFont.ttf");
	FontsRepository.RegisterFont(new FontFamily("CustomFont"), FontStyles.Normal, FontWeights.Normal, data);
	FontBase customFont;
	FontsRepository.TryCreateFont(new FontFamily("CustomFont"), FontStyles.Normal, FontWeights.Normal, out customFont);
	editor.CharacterProperties.Font = customFont;
	string text = "w";

	StringBuilder modifiedText = new StringBuilder();
	foreach (char character in text)
	{
		modifiedText.Append(character > 256 ? character : (char)(character + 61440));
	}

	text = modifiedText.ToString();

	editor.InsertRun(text);
}

Although Lab color space is currently unsupported, the provider should not throw exceptions that break the whole file import.

Currently this exception crashes the whole PDF document import. Instead we should simply skip the unsupported Action and import the rest of the PDF content correctly.

When importing a not embedded TrueType Font defined as Type 1 subtype Font an InvalidCastException is thrown.

In PDF document:

<< /BaseFont /Arial /Encoding 21 0 R /Name /F13 /Subtype /Type1 /Type /Font >>

In Adobe Reader:

When a TrueType font is defined, the mapping of character codes to glyph indices depends on the built-in cmap table mappings defined in the font and the Encoding property defined in the PDF dictionary.

However, the current implementation maps all characters with cmap tables for Microsoft Symbolic and Macintosh Roman, which causes incorrect mapping results, e.g. space characters are mapped to an Ê glyph.

The issue is also described in the following public item: TryGetCharCode for OpenTypeFont uses wrong cmap and returns wrong charcode.

Workaround: Change the font  of the TextBoxField's widget appearance:
foreach (var widget in field.Widgets)
{
    widget.TextProperties.Font = FontsRepository.Helvetica;
}

We should implement the logic for getting character codes from Unicode when using CFFFontSource.

Workaround: The font may be changed by creating a similar font with FontsRepository.TryCreateFont(...) method.
Telerik.Windows.Documents.Fixed.Model.Fonts.FontsRepository.RegisterFont(new Telerik.Documents.Core.Fonts.FontFamily("Arial"), Telerik.Documents.Core.Fonts.FontStyles.Normal, Telerik.Documents.Core.Fonts.FontWeights.Normal, fontData); // fontData is a byte[] keeping the font definition

FontBase font;
bool hasCreatedFont = FontsRepository.TryCreateFont(new FontFamily("Arial"), out font);
 
foreach (TextField field in document.AcroForm.FormFields.OfType<TextField>())
{
    if (hasCreatedFont)
    {
        foreach (var widget in field.Widgets)
        {
            widget.TextProperties.Font = font;
        }
 
        field.TextProperties.Font = font;
    }
}