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.

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

When creating a GradientStop, an alpha channel of the color could be applied. However, this setting is not respected it the result document and the gradient is with full opacity.

Steps to reproduce:
1. Create a gradient with an alpha channel:

RadFixedDocument document = new RadFixedDocument();
RadFixedPage page = document.Pages.AddPage();
FixedContentEditor containerEditor = new FixedContentEditor(page);

LinearGradient linearGradient = new LinearGradient(new Point(0, 0), new Point(30, 30));
linearGradient.GradientStops.Add(new GradientStop(new RgbColor(10, 0, 207, 0), 0));
linearGradient.GradientStops.Add(new GradientStop(new RgbColor(10, 0, 102, 204), 1));

containerEditor.GraphicProperties.FillColor = linearGradient;
containerEditor.DrawRectangle(new Rect(10, 10, 48, 29));

2. Export the document to PDF

Observed: The alpha channel is not respected and the gradient is with full opacity

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

When a document is exported with a cross-reference stream, the stream is missing the required according to the specification Length property. Although most of the viewers open the document without any issues, some cannot. Such documents cannot be opened in MS Edge.

By specification, the InteractiveForm fields can have the same name if they are descendants of a common ancestor. Such fields are different representations of the same underlying field; they should differ only in properties that specify their visual appearance. When such a document is imported an ArgumentException: 'An item with the same key has already been added.' is thrown.

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.

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

Exporting document with a missing image is caused by handled Exception on import for DecodeParms containing null or stream object. Currently, PdfProcessing supports only decode parameters containing simple types. The case when some dictionary value is null or stream object should be implemented.

Another case is when the whole dictionary/stream is null. In this case, an ArgumentNullException is thrown.

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 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).

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. 

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 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.

The issue is reproducible only with nested tables - tables positioned inside some other table cell. When using simple tables the text is always wrapped and rendered correctly. This may be used as a workaround for scenarios which allow replacing nested tables with simple ones.

This may cause either big distance between some glyphs, or overlapping glyphs.

The NotImplementedException is thrown while getting the color from unsupported color space (for example ICC). This exception occurs during the import of shading patterns with gradient stops using this color space or during the import of tiling pattern with underlying color space.

Available in R2 2018 Official Release Version.

When documents are exported to PDF, the creation date and modification date are not expected, or, when the time zone is with negative offset, the documents are invalid (detected by validation tools).

Trying to clone the Signature of a SignatureField leads to InvalidOperationException as the FieldName of the cloned signature is already set.