Currently, the search functionality in the Report Viewer only matches the exact text as it is displayed on the screen. For example, if a value is formatted as "1,469", searching for "1469" yields no results.
I would like the search functionality to work against the underlying data value. Users should be able to find numeric values even if they don't include the thousands separator (comma) or other formatting in their search query. This would make the report much more user-friendly and consistent with how users expect search to work.
- Actual Value: 1469
- Displayed Text: 1,469
- Expected Search Behavior: Searching for "1469" should highlight "1,469".
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.
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.
.png){kind=avatar}
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
- "Table Wizard"
- Current Data Sources
- Add New Data Sources
- Select "Object Data Sources
- I select my Assembly and data object.
- I select the Data source Member
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:
