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 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.
Currently, the desktop viewers don't allow adding custom headers to their requests to the service.
In HTML5-based web viewers, this is possible through the AjaxPrefilter event.
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":
Using the text-indent CSS setting results in part of the text on the first line being cut off:
I use the kendovalidator before rendering the report to check the correct parameter of initial and final date.
However, the validation fails because additional inputs (for the "Send Email" functionality) are included in the HTML output of the viewer even though I have disabled it.
I believe that if the "Send Email" option is disabled the mail data panel should not be created.
I cannot localize the messages of the Angular and React report viewers using the suggested approaches:
The only alternative is to use the approach from the Localization of the HTML5 ReportViewer Explained - Telerik Reporting article, which I can do only by loading the string resources script in index.html of the SPA.
Please note the spelling error in the k-notificaiton-error class name. Should be k-notification-error:
<div class="trv-parameter-error k-notification k-notificaiton-error" style="">
<span class="k-notification-status k-icon k-i-x-outline"></span>
<span class="trv-parameter-error-message k-notification-content">Parameter value cannot be empty.</span>
</div>
Because of this, error messages are rendered with incorrect color (should be red):
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.
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:
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:
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.