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.

Reading a password protected archive by passing a wrong password doesn't notify the user that the password is wrong. Accessing one of the entries in the archive throws a generic "Invalid data" exception.

Steps to reproduce:
1. Create a zip file with password.
2. Open the same archive with the API passing wrong password and then try to one of the entries.
Observed: InvalidDataException is thrown when trying to read one of the entries in the archive.
Expected: The exception should be more meaningful and if possible occur when reading the archive. There should be API allowing to check if the password is correct.

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.

In scenarios when center and right tabs are used for aligning the paragraph content to both left and right the text content in the exported PDF is not positioned as expected.

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

CellSelection.SetValue method causes memory leak of CellReferenceRangeExpression objects in some cases when cell value is referenced by formulas. The memory leak is small, but the remaining CellReferenceRangeExpression continue to listen to some events, causing performance issues when their number become large - the time to set the value increases with each set.

Table and table cell borders are not evaluated according to inheritance and conflict resolution rules. A conflict will occur when different borders from the table and table cell are overlapping. 

The GetActualValue method of the TableBorders and TableCellBorders could potentially return an incorrect value in some of the following scenarios:

Scenario 1:
A table has cell spacing set to 0. Meaning that the table and table cell borders will overlap.
The table borders have defined all of its borders with border style "Single".
The table cell borders have all of its borders defined with border style "None".

Expected result: the resulting borders should have the border style set to "None" for the location where the table and the cell borders are overlapping.

Scenario 2:
A table has explicitly defined that its right border is with border style "None".
The table has a table style applied with defined border style of type "Single" for all table borders.

Expected result: All of the table borders except the right border should have border style of "Single".

The problem is mostly visible when exporting to PDF and RTF format.

TableRow which has defined an only val attribute of the trHeight is imported as a row with auto height. By the specification, this is right, but MS Word takes the val value as row height. Also MS Word exports "At Least" row height with only 'val' set.

Workaround: Iterate through the table rows and set them HeightType to Exact or AtLeast:

foreach (var row in this.document.EnumerateChildrenOfType<TableRow>())
{
    row.Height = new TableRowHeight(HeightType.AtLeast, row.Height.Value);
}

LineInfo objects are not cleared when there are tables in the document being exported to PDF which leads to OutOfMemoryException.

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