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.

Generate a sample document with RadPdfProcessing and export it with AES-256 encryption. Try to open it on an iPhone with the default Pdf Viewer of iOS. The document is empty. However, the mobile version of Adobe for iOS opens the document successfully.

I'm working on a project that has a service component that will be generating Excel xlsx documents for distribution.  While there is a UI for administrative tasks, the service itself will run without an interface.  I'm using the Documents.Core, and several other associated libraries to accomplish this.  Two issues I've encountered, one is setting up the project with the appropriate libraries and keeping the version in sync with the Admin application, second is protecting those libraries once they are packaged for release.  I had a support ticket open to determine how to accomplish the latter, but the first is still a manual issue.  

So the feature request is to include the ability in the project templates and/or Convert to Telerik WPF Application to support a headless document solution.  It would ideally include (only) the required libraries and maintain their linkage to the appropriate library version with the rest of the solution which occurs with a full Telerik WPF UI app.  It would also include the necessary boilerplate code and references to properly protect the libraries.  I was referred to another feedback request on improving the overall library protection build process, but while related, what I'm asking for here is not exactly the same.

We would like to have image formats like JPG, PNG and TIFF supported in addition to the PDF and Office document support in DPL.

Attached a project to demonstrate some issues we're seeing that need resolving in order to use the component.

1. When using a font like Tahoma on a form field, the value no longer displays or contains garbled text.

2. Input file is 24KB, output is 2MB!

3. Rotated field lose their rotation after being flattened.

4. Simulate merging with other files, 100 times the file is now 150MB! It's as though it's not re-using the fonts, but keeps adding the same ones.

5. when merging, but not flattening, the form fields are all lost on pages after page 1

Even without flattening the form the Barcode font gets lost.

Noticed that manually setting the font using the font name with spaces seems to work.

Other custom fonts on our form appear to work, however the Free 3 of 9 does not.

1. Line Height is not converted properly.  for example, if we set the line height is 1.5 in angular UI editor, in PDF is not shown properly,

2. Table alignment is not proper -  After resizing the in the angular editor, the same alignment is not converted in PDF. I think colgroup and cols custom tags are not considering while converting the PDF.