There are scenarios when the default value of the columns is changed and may be different from 65. However, RadSpreadprocessing always exports the non-custom column values as 65.

WORKAROUND: After importing the XLSX file you may make all columns to have custom values in order to preserve the column widths after the export. The following code snippet shows how this may be achieved for some Worksheet instance:

CellRange usedRange = worksheet.UsedCellRange;

for (int i = 0; i < usedRange.ColumnCount; i++)
{
    ColumnSelection column = worksheet.Columns[i];
    double width = column.GetWidth().Value.Value;
    column.SetWidth(new ColumnWidth(width, true));
}

Add support for superscript and subscript font effects for cell formatting. Currently, this is not supported by the model and is omitted on import.

Comparison operators (equal '=', not equal '<>') doesn't work as expected with references to empty cells. For example, expressions of type '=IF(A1="", TRUE, FALSE)' are evaluated to false when A1 cell is empty. 

In MS Excel, such expression is evaluated to TRUE if the cell is empty - i.e. empty cell value is considered equal to an empty string "".

Workaround: Use ISBLANK function if possible. Its results are consistent with MS Excel.

For instance, when exporting FLOOR.MATH function a #NAME error is displayed initially.

Workaround: Select the cell in Excel, click in the formula bar and press Enter without changing anything. This fixes the #NAME error and Excel manages to successfully display the function result.

Add support for CHOOSE function. CHOOSE uses the number parameter to return a value from the list of value arguments. 

A list of the supported functions is available at http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/functions

This function can be implemented as a custom function. Check the following resources for more details on how to achieve that:

- http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/custom-functions
- https://github.com/telerik/xaml-sdk/tree/master/Spreadsheet/CustomFunctions

Available in R2 2017 Official Release.

Add support for TRIM function. TRIM removes all spaces from text except for single spaces between words.

A list of the supported functions is available at http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/functions

This function can be implemented as a custom function. Check the following resources for more details on how to achieve that:

- http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/custom-functions
- https://github.com/telerik/xaml-sdk/tree/master/Spreadsheet/CustomFunctions

Available in R2 2017 Official Release.

Formulas like =0.0001/10 or formulas that produce small values results in 0 instead of exponential numbers.


Available in LIB version: 2017.1.313

Add support for strikethrough font effect for cell formatting. Currently this is not supported by the model and is omitted on import.

When the default number formats for Accounting and Currency are used and the current culture is Russian, the number format is not parsed correctly.

Add support for array formulas (CellFormulaType "array"). These formulas can accept as parameters and return results containing whole arrays (one- or two- dimensional) of data. In MS Excel, such formulas are inserted with CTRL + SHIFT + Enter, and visualized enclosed with curly brackets ('{' and '}'). 

The data validation is working. However, the text can't be localized by MS Excel with installed non-English language pack after import/export with SpreadProcessing. The problem is caused by an interpretation of the data validation rule as a text instead of as a formula.

Xlsx documents with global print area defined cannot be imported. Message box "The name that you entered is not valid." is shown and internally SpreadsheetNameException is thrown. 
By default, print areas are defined in the xlsx files for specific spreadsheet:
<definedName name="_xlnm.Print_Area" localSheetId="0">Sheet1!$A$1</definedName>
but this one is without localSheetId property specified.

MS Excel can import such document and even preserve the area, but do not respect it and doesn't have UI to clear it.

By OOXML specification, this attribute is optional:
<xsd:attribute name="localSheetId" type="xsd:unsignedInt" use="optional"/>

Workaround 1 (includes processing the document with MS Excel):
- Open the document in MS Excel
- Choose Formulas -> Defined names -> Named Manager
- Choose Filter -> Names with errors
- Find all Print_Area defined names and delete them
- Save the document

Workaround 2:
- Delete all print areas with OpenXML SDK


Available in LIB version: 2017.1.213

When there is a defined name referring many cells with long values, the Value of the defined name is string which does not contains the values of all the referred cells and ends with "...".

When importing and exporting xlsx document with email address hyperlink the exported document shows invalid document message when opened in Excel: "We found a problem with some content in 'file.xlsx'. Do you want us to try to recover as much as we can? If you trust the source of thes workbook, click Yes.". The document can be only partially recovered and information is lost.

When printing or exporting to PDF, the left border of A1 cell is not printed/rendered.

When there is some long number value in merged cell and this cell is autofit, then in Excel the cell is visualized with "#####" because the column width is not enough.

Workaround: As a workaround in some scenarios it is possible to call Merge method after AutoFitWidth method in order get the correct column width.

When the column width is not an integer number, but a decimal fraction one, the width which is exported is not calculated correctly. 

For example, if there is a cell with some text and its column's width is autofit, it's exported with different actual width.

In addition, if the exported xlsx file is imported back in the Spreadsheet, the column width is a bit different from the one which was exported (only for the first export-import roundtrip).

The COUNT function counts the number of cells which contain numbers.

Description from Microsoft here: https://support.office.com/en-US/article/COUNT-function-A59CD7FC-B623-4D93-87A4-D23BF411294C.

Workaround: Implement such a custom function. See Custom Functions help article here: http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/custom-functions .