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.
Currently, logarithmic axes do not support the LabelStep and MajorStep properties, which makes it difficult to control label density and avoid visual clutter for larger data ranges.
Adding support for these settings (similar to numerical scales), or providing a way to conditionally hide axis labels, would significantly improve readability and axis customization.
I have a Telerik report designed in the Standalone Report Designer. In the HTML5 Report Viewer, the report seems to be correct, but when I export the report in PDF, the word order changes.
The problem occurs in the HTMLTextBox when rendering in PDF and previewing in the Standalone Designer with both Skia and GDI+.
In the TextBox, the same text is displayed as expected.
When previewing in the HTML Report Viewer, the Arabic text seems fine.
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.
Is there a telerik reporting xml schema definition document somewhere? This is so that we can more effectively get AI to automatically build telerik reports.
WPF report viewer crashes when launching it the second time. The issue appears to occur only when having a trial license activated.
System.Windows.Data Error: 23 : Cannot convert '<null>' from type '<null>' to type 'System.Uri' for 'en-US' culture with default conversions; consider using Converter property of Binding. NotSupportedException:'System.NotSupportedException: UriTypeConverter cannot convert from (null).
at System.ComponentModel.TypeConverter.GetConvertFromException(Object value)
at System.ComponentModel.TypeConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
at System.UriTypeConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
at MS.Internal.Data.DefaultValueConverter.ConvertHelper(Object o, Type destinationType, DependencyObject targetElement, CultureInfo culture, Boolean isForward)'
Exception thrown: 'System.NullReferenceException' in Telerik.ReportViewer.Wpf.dll
Object reference not set to an instance of an object.
I'm using VS 2022, the demo reporting (Telerik_Reporting_2026_Q1_20_0_26_211). When using the "Telerik Report 2026 Q1 Wizard", I select the following
See attach file when I finish the wizard.
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).
We are using "@progress/telerik-angular-native-report-viewer": "29.26.211"
Seems options Fit to page/Fit to width are mixed
Fit to page does what Fit to width should be doing and vice versa
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":
In the Report Book’s Edit Parameters dialog, non‑mergeable parameters only show index 0 in the dropdown, even when multiple report instances are present:
Other indexes can be applied only by manually typing the value into the combo box, but this behavior is not intuitive and makes it unclear that parameters can be assigned per instance.
Consider adding support for the `start` attribute of the `ol` element in HtmlTextBox. This would allow us to change the start counting:
in the expression editor i have a html tag like this...
<ol style="list-style-type: lower-roman" start="2">
design view on the expression editor correctly shows the indented list starting with ii (2).
On the main report view and print, it only shows as i (1).
Yet any editing it switches back to ii (2);
---
Comment from admin: The HtmlTextBox item does not (yet) support the `start` attribute (please check Styling and Formatting HtmlTextBox). Therefore, the result in the report preview/print is the expected one, while the design view is misleading.
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:
When using A4 paper or narrow-edge leading media the Web Viewer prints everything perfectly.
When using a 60mm x 30mm label, therefore "wide-edge" leading media, the web viewer prints the label in landscape, even though the print is in portrait!
Just because the media is "landscape" surely it is the print on the media that determines the orientation?
When using the Windows System Print Dialogue this does not occur, on the using the print from the Web Viewer. This is because the Web Viewer converts it to PDF first to print (I believe). Surely, in the code you can state NOT to rotate, OR rotate it back to the correct orientation for wide edge leading media.
The label design is portrait so all the "print / pdf" code needs to do is to query this and not assume that wide edge leading media automatically prints in landscape.
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:
When I invoke a cancellation before the report processing starts, the expected behavior is that the report should really not even begin processing, but it runs to completion.
When I export to XLSX, RTF, and CSV formats, and try to cancel the report a few seconds later, so that cancellation is signaled while report processing is already occurring, it doesn't stop. The expected behavior is that a TaskCanceledException should be raised, and the report processing should stop, but the report runs to completion. In PDF, DOCX, and PPTX, this works as expected.
The HTML5-based report viewers send 404 request to `/sass/fonts/kendo-font-icons.ttf` when font icons are being used: