I have localized a report with a Graph in the 'ar-SA' culture.
When exporting to PDF from the viewer, the report is generated as expected. In the Report Viewer's Preview, though, the Graph Legend and Labels are not correct:
I am using Native Blazor Report Viewer, but the problem also reproduces in the HTML5-based web viewers, with all the themes I have tested.
Request:
Add a RedisStorage constructor overload that accepts StackExchange.Redis.IConnectionMultiplexer rather than only the concrete ConnectionMultiplexer.
Current behavior:
new RedisStorage(ConnectionMultiplexer connectionMultiplexer) requires the concrete type.
Problem:
Modern ASP.NET Core apps manage a single shared multiplexer through DI and expose it as IConnectionMultiplexer — the abstraction recommended by StackExchange.Redis, and the same type
Microsoft.Extensions.Caching.StackExchangeRedis uses via its ConnectionMultiplexerFactory (which returns IConnectionMultiplexer). To call RedisStorage we are forced to downcast our IConnectionMultiplexer back to
ConnectionMultiplexer. This is fragile and it prevents passing test doubles or decorators (e.g. for instrumentation/logging).
Proposed change:
Add RedisStorage(IConnectionMultiplexer connectionMultiplexer), plus a databaseNumber overload (RedisStorage(IConnectionMultiplexer connectionMultiplexer, int databaseNumber)). ConnectionMultiplexer already
implements IConnectionMultiplexer, so this is fully backward-compatible — existing callers that pass a concrete instance keep working unchanged. Everything RedisStorage needs is available on the interface
(GetDatabase for string operations and LockTake/LockRelease, GetSubscriber, GetServer).
Benefits:
- Clean dependency-injection integration with a shared, app-managed multiplexer.
- Unit-testability via a mocked IConnectionMultiplexer.
- Consistency with StackExchange.Redis guidance and Microsoft's own caching abstractions.
Note:
Please target the maintained Telerik.Reporting.Cache.StackExchangeRedis package (the .2 variant appears discontinued after 18.2.24.806 and has no 19.x/20.x release).
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">
I am trying to use the following HTML content for the HtmlTextBox item:
<span style="font-weight:bold">Label 1:</span> <span>Data 1</span> <span style="font-weight:bold"> Label 2:</span> < span>Data 2</span>
However, the non-breaking space between the spans (label 1/data 1 and label 2/data 2) is not preserved.
I have a custom assembly with default 'version', 'culture', and 'publicKeyToken'.
When I reference the assembly in the 'assemblyReferences' element only with its 'name', the Reporting Engine recognizes it.
If I reference it with the full version, '1.0.0.0', it also works.
However, when I set the 'version' to '1.0.0', the Reporting Engine throws, stating that the assembly is not trusted and must be referenced in the 'assemblyReferences' element.
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 attached sample has a simple table with two row groups, and "header" rows created via "Insert Row -> Outside Group - above".
The groups have "keep together" set.
But despite this, the header rows render at the bottom of one page, with data rows on the following page. This should never happen, I can't think of any case it would be expected (it would be like having "Chapter 2" at the bottom of a page when the text for it starts on the next page).
I also have a sample with just 1 row group, but with 2 detail rows, and the same thing happens. It only appears to work when there's just 1 row group and 1 detail row.
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.
greetings
Summary
When the Web Report Designer is initialized with non-English string resources (via window.telerikWebDesignerResources), the authentication type selector in the Web Service Data Source wizard behaves incorrectly. Even though "Sin autenticación" (the translated value of WebServiceDataSourceNoAuthentication) is visually selected in the dropdown, the wizard behaves as if a different authentication type is selected — displaying additional required credential fields and blocking progression.
The issue does not occur when using English string resources (WebServiceDataSourceNoAuthentication = "No authentication").
---
Steps to Reproduce
1. Configure a Blazor Web Report Designer with Spanish (es-CO) custom string resources using window.telerikWebDesignerResources:
// WebReportDesignerStrings.es-CO.js
export class WebReportDesignerStringsBase {
constructor() {
// ...
this.WebServiceDataSourceNoAuthentication = "Sin autenticación";
// ...
}
}
// Load resources before designer renders
window.telerikWebDesignerResources = new WebReportDesignerStringsBase();
2. Open the Web Report Designer in the browser with the Spanish resources active.
3. Add a new Web Service Data Source.
4. In the wizard URL step, observe the authentication selector — it shows "Sin autenticación" as the selected option.
5. Attempt to proceed through the wizard.
---
Expected Behavior
With "Sin autenticación" selected (equivalent to "No authentication"), the wizard should:
- Require only the Service URL field
- Not display credential input panels
- Allow proceeding to the next step without authentication configuration
---
Actual Behavior
Despite "Sin autenticación" being visually selected, the wizard behaves as if a different authentication type (Basic or 2-step) is selected:
- Additional authentication configuration panels appear or are required
- The wizard blocks progression expecting credential inputs
- The behavior is identical to what occurs when "Basic" or "2-step" is selected
---
Root Cause Analysis
The designer's compiled JavaScript (webReportDesigner) appears to compare the selected authentication type against the English string "No authentication" internally, rather than against a stable enum or index value. When the display text is "Sin autenticación", this comparison fails and the wizard falls through to a non-"no auth" code path.
Evidence: applying the temporary workaround of keeping WebServiceDataSourceNoAuthentication = "No authentication" (English text) in the es-CO resources file resolves the issue completely — the wizard functions correctly while all other strings remain in Spanish.
---
Workaround
In the non-English string resources file, keep WebServiceDataSourceNoAuthentication in English:
// workaround: keep English value until Telerik fixes internal comparison
this.WebServiceDataSourceNoAuthentication = "No authentication";
---
Minimal Reproduction
@* ReportEditor.razor *@
@page "/reportEditor"
@using Telerik.WebReportDesigner.Blazor
<WebReportDesigner DesignerId="wrd1"
ServiceUrl="apiReport/reportdesigner" />
// Loaded before designer renders via IJSRuntime.InvokeVoidAsync
window.telerikWebDesignerResources = {
WebServiceDataSourceNoAuthentication: "Sin autenticación",
// ... other keys
};
---
Additional Notes
- Both es-CO and en-US string resource files contain 971 keys each — the issue is not caused by missing keys.
- The designer correctly picks up the localized strings for all other UI elements; the bug is isolated to the authentication dropdown value comparison logic.
- Confirmed on version 19.1.25.521; not tested on earlier versions.
thank for your attention.
have a nice day.
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".
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 generating PDF/UA files, we need to have special objects that are read by an internal system but ignored by screen readers. This cannot be achieved with the existing functionality.
It would be beneficial if we could configure reports so that specific objects inside the generated document are ignored by screen readers. For example, by setting a special value to the AccessibleRole property of a text box.
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