When editing a report that has a watermark of type BackgroundOverlay with Sizing set to TopLeft, the design time preview of the watermark does not scale with the zoom level correctly.
The preview displays correctly only at 100% zoom level.
The report processing is stopped and the following message is shown when trying to preview a report that uses one of the available DataDirect drivers in a .NET Core application.

The same report can be previewed successfully in a .NET Framework application.
Requesting a feature to allow some sort of selection feature on the "Send Mail Dialog". The issue that we're having is if the user needs to email a report to 5 or 10 people it becomes very daunting, ugly and difficult for them to achieve this without making errors in typing out every single email.
Also, in most cases the user might not know the individuals email official email address in the organization so they have to go look up every single one. If there was a drop down selection or an auto predict while typing then once clicked it grouped up the name to make it look cleaner and easier for them to find the email addresses that would be wonderful. Here's an example of what it looks like right now.
When I try to export a ReportBook to TIFF as explained in Exporting a report to a multi-document format, I receive an exception related to the file '.../report/image.tif' that cannot be created.
When I create the folder '.../report', there is another exception message:
'The process cannot access the file '...\report\image.tif' because it is being used by another process.'
The above error was thrown the second time the ReportProcessor tried to access the 'CreateStream' method from the code snippet in the above article. The 'image.tif' file is created and contains only the first report from the ReportBook.
With version 15.0.21.112 the last exception is not thrown and the 'image.tif' file contains all reports from the ReportBook.
The Standalone Report Designer allows users to add Anchoring to an item even if its container has KeepTogether set to False. This is not valid and can break report definitions without a warning.
The reports can be fixed by editing the XML code of the definition manually and setting the KeepTogether property to True.
Since upgrade to openXML 3.0.0 we get exceptions at runtime when we want to create a report in XLS.
While a feature request has been filed here: https://feedback.telerik.com/reporting/1631967-openxml-renderings-should-work-with-documentformat-openxml-3-0-0-and-newer one could argue it is a bug. Anyway, i raise this issue here to have some extra attention to it.
System.TypeLoadException
HResult=0x80131522
Message=Could not load type 'DocumentFormat.OpenXml.Packaging.ImagePartType' from assembly 'Telerik.Reporting.OpenXmlRendering.2.7.2, Version=17.2.23.1114, Culture=neutral, PublicKeyToken=a9d7983dfcc261be' due to value type mismatch.
Source=Telerik.Reporting.OpenXmlRendering.2.7.2
StackTrace:
at Telerik.Reporting.OpenXmlRendering.Spreadsheet.Worksheet..ctor(Workbook workbook, WorksheetPart worksheetPart)
at Telerik.Reporting.OpenXmlRendering.Spreadsheet.Workbook.AddWorksheet()
at Telerik.Reporting.ExcelRendering.Report.Render(IWorkbook workbook)
at Telerik.Reporting.OpenXmlRendering.Spreadsheet.SpreadsheetReport.Telerik.Reporting.Processing.IRenderingExtension.Render(Report report, Hashtable renderingContext, Hashtable deviceInfo, CreateStream createStreamCallback, EvaluateHeaderFooterExpressions evalHeaderFooterCallback)
at Telerik.Reporting.Processing.ReportProcessor.RenderCore(ExtensionInfo extensionInfo, IList`1 processingReports, Hashtable deviceInfo, IRenderingContext renderingContext, CreateStream createStreamCallback)
at Telerik.Reporting.Processing.ReportProcessor.ProcessAndRender(String format, ReportSource reportSource, Hashtable deviceInfo, IRenderingContext renderingContext, CreateStream createStreamCallback)
at Telerik.Reporting.Processing.ReportProcessor.ProcessAndRenderStateless(String format, ReportSource reportSource, Hashtable deviceInfo, IRenderingContext renderingContext, CreateStream createStreamCallback)
at Telerik.Reporting.Processing.ReportProcessor.<>c__DisplayClass47_0.<RenderReport>b__0(SingleStreamManager sm)
at Telerik.Reporting.Processing.ReportProcessor.RenderReportSafe(Func`2 renderCallback, String format, IRenderingContext renderingContext)
at Telerik.Reporting.Processing.ReportProcessor.RenderReport(String format, ReportSource reportSource, Hashtable deviceInfo, CancellationToken cancellationToken)
at Telerik.Reporting.Processing.ReportProcessor.RenderReport(String format, ReportSource reportSource, Hashtable deviceInfo)
at Indato.Reporting.TelerikReports.<>c__DisplayClass1_0.<RenderReportAsync>b__0() in C:\Users\leosiepel\Source\Workspaces\Indato\Indato-Main\Indato.Reporting\TelerikReports.cs:line 42
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
When certain fonts are used, the text of reports exported to PDF looks different between the Skia and GDI rendering engines, even if the fonts are fully embedded.
For example, if the TT Norms font is used and the report is exported to PDF (full font embedding) with both engines, the document rendered by Skia is much larger and looks different than the GDI-rendered document.
The Export dropdown menu looks like the following image when using Kendo UI 2023.2.606+
When generating PDF/UA files, we need to have special objects that are read by an internal system but ignored by screen readers. This cannot be achieved with the existing functionality.
It would be beneficial if we could configure reports so that specific objects inside the generated document are ignored by screen readers. For example, by setting a special value to the AccessibleRole property of a text box.
If the file `WebReportDesignerSettings.json` doesn't exist before running the Web Designer REST Service, the latter will create it. However, the file will remain locked and the service will throw the exception:
"The process cannot access the file '/app/Telerik_Reporting/WebReportDesignerSettings.json' because it is being used by another process."
When the file exists, the problem will be avoided, which leads to the workaround - create the file at a starting point of the application. Here is a sample code:
static void InitFile()
{
var path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "Telerik Reporting", "WebReportDesignerSettings.json");
File.Create(path).Close();
}
To allow localization for the WebReportViewer in Version 17.1.23.718 and before, it was enough to provide a customized Version of "telerikReportViewer.stringResources.js", which extended the property "window.telerikReportViewer.sr".
This worked for both, the WebReportViewer and the Preview of the WebReportDesigner. With version R3 2023 SP1 (17.2.23.1114), this approach does not work anymore.
When an item has borders applied and the report is exported to PDF, the border lines "stick out" at the joints. The image below illustrates this.
Some additional information about the issue:
When rendering a Report in PDF with Skia Sharp, the Arial Bold Italic font is rendered as Normal. Arial Bold and Arial Italic fonts are rendered correctly.
When rendering with GDI+ all fonts are displayed correctly.
Currently, I can send only String content when making a POST request with the WebServiceDataSource component.
My Web API requires me to the content as Form URL Encoded and I cannot do that with the WebServiceDataSource component, and have to use the ObjectDataSource component to manually request the data correctly.
If a WebServiceDataSource has inline JSON data for design-time preview, this inline data is not used when the report is designed with the Web Report Designer. Instead, the data is requested from the service both during design time and during live preview.
On the other hand, the Standalone Report Designer works as expected. I.e. inline data is used during design time and live data from the service is used during the preview.