In the 2025 version of the Documents packages, "TimeSpan? timeout" were added to a number of interfaces, with the old versions obsoleted, for example: IWorkbookFormatProvider.Import & IWorkbookFormatProvider.Export.

This is a very strange choice, because this limits the flexibility of the interfaces for no reason at all. By only providing the TimeSpan parameter and not a CancellationToken is currently impossible to cancel the operation because e.g. an API request was canceled.

Internally these methods are implemented by first creating a cancellation token using

using CancellationTokenSource cancellationTokenSource = CancelationTokenSourceFactory.CreateTokenSource(timeout);

the token from this CancellationTokenSource is then passed to a protected method. Because this internal method uses a CancellationToken anyway, there is practically 0 development cost to exposing this in the interface, which makes the choice not to do so even more confusing.

The interfaces should expose methods that take a CancellationToken instead of a TimeSpan. This would allow for the same functionality as the TimeSpan parameter, by simply passing a cancellation token with a CancelAfter set with a TimeSpan, and an extension method could be provided for the interface which does exactly that, so users can still call these methods with a TimeSpan parameter if they wish to do so for convenience.

Please, in the next version, make these interfaces methods like this:

Workbook Import(Stream input, CancellationToken cancellationToken = default);
void Export(Workbook workbook, Stream output, CancellationToken cancellationToken = default);

and, for convenience, add extension methods for these like this:

public static class WorkbookFormatProviderExtensions
{
    public static Workbook Import(this IWorkbookFormatProvider workbookFormatProvider, Stream input, TimeSpan? timeout)
    {
        using CancellationTokenSource cancellationTokenSource = CancelationTokenSourceFactory.CreateTokenSource(timeout);
        return workbookFormatProvider.Import(input, cancellationTokenSource.Token);
    }
}

Affected interfaces I've run into so far:

• Telerik.Windows.Documents.Spreadsheet.FormatProviders.IWorkbookFormatProvider
• Telerik.Windows.Documents.Common.FormatProviders.IFormatProvider<T>

There may be more with this same pattern, I haven't checked.

After Excel introduced the dynamic array support, files produced with the older Excel versions have formulas that may be displayed with @ in some contexts. For example a file that had the following:

=SUM(IF(A1:A10=1, B1:B10, 0))

Will be displayed like so:

=SUM(IF(@A1:A10=1, B1:B10, 0))

This is done in order to preserve the behavior of the files created in older versions of Excel.

The files created by SpreadProcessing are also treated by Excel as if they are created by pre-dynamic array Excel. Please, introduce support for the new behavior.

MS Excel offers the following text styling options:

When importing a document containing a Plain Text SDT with multiple paragraphs an exception is thrown:

Telerik.Windows.Documents.Flow.Model.Annotations.StructuredDocumentTags.Builders.SdtBuilderFailureException: "This content control type cannot be inserted around multiple paragraphs."

Hi 

is there possible Telerik RadSpreadProcessing able to print repeat column on every printed page?

Telerik expose beautyfull document processing: you can automate a lot of thinks in document without user interaction.

But doesn't exists nothing about print this documents without user interaction: you have to open document on a webpage in a component and the print it.

For example: filling out a form can be done internally by process but not printed it.

Renato