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.

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. 

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.

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

When xlsx/docx document is imported, and its main story is with non-default name ('workbook. xml'/'document.xml'), e.g. workbook2.xml/document2.xml, NullReferenceException is thrown and the document is not imported.

Note: Such documents are usually produced after conversion from a template dotx/xlsm.

In the document produced by the mail merge, the date time formatting applied is not respected and the value is in its default format. 

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

When the last element in a table cell is an empty paragraph, the latter is skipped and not imported. It should be imported even if it's the only paragraph in the cell, as its properties could affect the layout and presentation (borders, colors, spacings).

Style properties defined in an element style selector are evaluated with higher priority over properties in a CSS class when importing from HTML.

For example if we have the following CSS style:

.sectionheading {
border: 10px solid red;
        }
td {
border: 10px solid black;
        }
and the class (.sectionheading) is applied on a table cell:

<td class="sectionheading">...</td>

The result in WordsProcessing after import of such HTML will be that the table cell has 10px black border. In MS Word and in the browsers (Chrome, Firefox...) the result will be that the cell has 10px red border.

If the Table's TableCellSpacing property is not divided by 2 when the document is exported to Docx or Rtf, this leads to incorrect rendering after the exported document is opened with another editor (RadRichTextBox, MS Word).

Workaround: Divide by two the Table's table cell spacing property value before export to Docx, RTF formats:
foreach (Table table in document.EnumerateChildrenOfType<Table>())
{
    table.TableCellSpacing /= 2;   
}

Table's 'cellspacing' and 'cellpadding' are not imported from HTML when the unit is not specified, e.g. <table cellpadding="25">. According to the HTML Specification (https://www.w3.org/TR/REC-html40/struct/tables.html#adef-cellspacing), the only permitted values are:
- only number
- number followed by percent.

MS Word imports it according to the specification (like WordsProcessing), but all of the browsers successfully imports values even with the px suffix, e.g. '25px'.

When a workbook (xlsx) contains a worksheet where some of the columns have width, bigger than the value written in the SpreadsheetDefaultValues (2000) an exception during the import 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.

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.

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

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.