I use the exportBegin event to prevent the default export logic. However, when I do that, the default viewer notification remains, and I have to hide it manually:
exportBegin: function (e, args) {
args.handled = true; // Set to true to cancel the default export behavior.
//...
$(".trv-notification").addClass("k-hidden");
},
When I display a report in a web report viewer, whose service is running on a server where one or more of the used fonts are not available, the first instance of the item(s) that use those fonts is being substituted with another font. The rest of the items do render with the original font, however.
This creates confusion and inconsistency. We should use the substituted font because it's used for measuring when using Print Preview mode in the web viewers, or when rendering to pdf via print/export.
The rendering extensions are currently loaded by the Telerik.Reporting.Processing.RenderingExtensionManager all at once in the main thread when the report processing starts. This is redundant because one report processing requires one rendering extension to be loaded.
In my Graph, I have set the AccessibleRole and AccessibleDescription. The alternative text is read correctly by the Acrobat Reader's 'Read out Loud' functionality.
The problem is that it keeps reading it multiple times.
When an HtmlTextBox contains a large HTML ordered list that exceeds a single page height, the generated PDF is cut at the pixel-level page boundary rather than at a text line boundary. This results in a line of text being visually split mid-glyph — part of the line appears at the bottom of one page, and the remainder is orphaned at the top of the next page.
To reproduce, create an HtmlTextBox that contains an <ol> with lots (>40) <li> items, so they span more than one physical page and export to PDF. Observe the page boundary where the list crosses a page — the split occurs mid-line.
Expected behaviour:
The renderer splits the HtmlTextBox content at a complete line boundary, consistent with how a plain TextBox behaves.
Actual behaviour:
The split occurs at the pixel-level page margin, cutting through a rendered text line.
I am using the ObjectDataSource component of the Standalone Report Designer. However, I get errors mentioning that types from `System.Private.CoreLib` cannot be loaded. This used to work in version 19.3.26.121. The workaround in the latest version is to manually register the `System.Private.CoreLib` assembly in the designer through `assemblyReferences` (File -> Options -> Add).
When using a report parameter of type string whose value resembles a date format (e.g., "3036-01"), the System.Text.Json serialization logic used by Telerik Reporting incorrectly treats the value as a date instead of a plain string. As a result, the parameter is serialized and displayed as a parsed DateTime value rather than the original text, leading to unexpected outputs such as "3036-01-01T00:00:00.0000000":
Consider adding support for the `start` attribute of the `ol` element in HtmlTextBox. This would allow us to change the start counting:
I have created an ellipse shape item and have set its Stretch property to True. Then, I have set the width of the item to be 1.5in, while the height is 1in, which results in a horizontally stretched ellipse on design-time:
However, when I render the report on Linux where the Skia graphics engine is used, the shape is not rendered properly:
After updating to the Q1 2026 release of Reporting, I get the following error when passing the value of a DateTime parameter from the main report to a DateTime parameter of a report that I open via the Navigate To Report action:
CSharp.Net10.ReportingRestServiceCorsDemo Error: 0 : Parameter /Date(1771253073461)/ does not match Epoch regex format! CSharp.Net10.ReportingRestServiceCorsDemo Error: 0 : Parameter /Date(1771253073461)/ does not match Epoch regex format!
The issue seems to occur only when directly passing the value of the DateTime report parameter, so as a workaround, I decided to create a new date using the Date() function. For example:
The HTML5-based report viewers send 404 request to `/sass/fonts/kendo-font-icons.ttf` when font icons are being used:
My report has a Text Watermark as part of the PageSettings, and is configured for Accessibility. The report contains a Page Header and Page Footer. In the Page Footer, there are two TextBoxes.
When I generate an accessible PDF with Telerik Reporting and use the Adobe Reader > Read Out Loud functionality, it doesn't read the content of the second TextBox in the Page Footer.
Currently, Telerik Reporting has a dependency on Microsoft.Data.SqlClient version="5.2.2".
This version may cause build failure when restoring packages due to locked package files.
See the following dotnet issue for more information about the problem: dotnet/SqlClient#2464
I have a report with an HtmlTextBox item, which contains an ordered list(<ol>). When I export this report to PDF, and inspect the logical tree of the document with a tool like the PDF Accessibility Checker, I can see that the span with the text is inserted above the number.
As a result, when I read the document with a screen-reading tool like Adobe's "Read Out Loud" feature or NVDA, the text is read before the current number in the list, which I find unexpected.