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.
The HTML5-based report viewers send 404 request to `/sass/fonts/kendo-font-icons.ttf` when font icons are being used:
Currently, graph axes do not provide a way to render separator lines between category groups. While this is generally not an issue for simple scenarios, it can make charts with nested categories difficult to read.
For example, when a graph displays multiple subcategories under a parent category (such as revenue ranges grouped by quarter), there is no built-in visual indicator showing where one parent category ends and the next begins.
It would be useful to provide support for category separators on graph axes, allowing report authors to visually separate category groups and improve readability when working with hierarchical data.
It would be great if you could introduce the ability to create custom reusable color palettes in Telerik Report Designer, so I don't have to declare the same set of colors for each chart I need them.
If you have a lot of graphs in your report then it is more convenient to change the color palette one place.
When using screen reader applications like JAWS or Narrator, those tools read accessible reporting PDFs in an incorrect order. For example, if I have two items in the report, the reader will read the second item first.
Additionally, images whose AccessibleDescription I have set may be read multiple times..
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.
Hi Team,
Even after giving the date format facing the inconsistency in the date field for some rows in the table when we export it to CSV file
<TextBox Width="1.036in" Height="0.24in" Left="0in" Top="0in" Value="= Fields.StartDate" Format="{0:MM'/'dd'/'yyyy h:mm tt}" Name="Opened Date">
We have spotted that PInvoke is now marked as deprecated (this applies even to the latest 0.7.124 version). In the description of the PInvoke.User32 NuGet package, it is mentioned that Microsoft.Windows.CsWin32 should be used instead:
Please consider replacing the deprecated package.
However, in my report, the Interactivity options do not show any property for Level. I am only seeing basic properties like Action, BookmarkId, DocumentMapText, TocText, etc.
The Level field is completely missing.
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".
Consider adding support for the `start` attribute of the `ol` element in HtmlTextBox. This would allow us to change the start counting:
The HTML5 Report Viewer uses inline templates which may require enabling the unsafe-eval CSP policy.
The viewer should migrate to using CSP templates as shown in Getting Started with Content Security Policy (CSP) Templates - Kendo UI Templates - Kendo UI for jQuery.
When exporting an SVG image to PDF, polylines with stroke-dasharray are rendered incorrectly — the dash pattern is not applied.
Additionally, polylines with a stroke-width exhibit visual artifacts such as pixelation or inconsistent thickness.
Step by step instructions or code snippets how to reproduce the problem
- Save svg content (see below) as a file c:\test_svg_line_stroke.svg
- Create an empty report
- Add a picture box
- Select a value for the picture box - use file c:\test_svg_line_stroke.svg
- Go to preview - SVG is correct
- Click Export->Acrobat (PDF) file and export a PDF file
- Open PDF file to verify that the red line in a bottob does not have stroke-dasharray applied
If there's no black line with no stroke-dasharray - the red line in a bottom looks correct
test_svg_line_stroke.svg
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xml="http://www.w3.org/XML/1998/namespace" width="500" height="400" viewBox="0, 0, 500, 400" preserveAspectRatio="xMinYMin" transform="scale(1)">
<polyline points="100, 100 400, 100" stroke-width="7" stroke-dasharray="40 40" style="fill:none;stroke:#FF0000;" />
<polyline points="100, 200 400, 200" stroke-width="5" style="fill:none;stroke:#000000;" />
<polyline points="100, 300 400, 300" stroke-width="7" stroke-dasharray="40 40" style="fill:none;stroke:#FF0000;" />
</svg>
test_svg_line_stroke.svg - svg source file
test_svg_line_stroke.trdp - report with a picture box with SVG image
test_svg_line_stroke.pdf - generated PDF file