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.

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

1. Save svg content (see below) as a file c:\test_svg_line_stroke.svg
2. Create an empty report
3. Add a picture box
4. Select a value for the picture box - use file c:\test_svg_line_stroke.svg
5. Go to preview - SVG is correct
6. Click Export->Acrobat (PDF) file and export a PDF file
7. 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

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.

It would be really useful if EntityDataSouce was updated to support Entity Framework Core contexts. EF Core depends on Standard 2.0 so can run on .NET Core or the full framework.

Currently, if I want to see what the device info settings for an extension like the PDF are, I need to open the documentation - Telerik Reporting Configuring the Output Formats PDF Device Information Settings - Telerik Reporting, then copy the setting that I wish to use in my code.

It would be easier and safer if the device information settings for each format were exposed as a public enum/class. On that note, it would also be easier if the available formats were exposed as well, instead of manually typing them. For example:

public static classTelerikDeviceInfoSetting
{
    public static class PDF
    {
        public const string DOCUMENTTITLE = "DocumentTitle";
        public const string DOCUMENTAUTHOR = "DocumentAuthor";
        public const string DOCUMENTSUBJECT = "DocumentSubject";
        public const string DOCUMENTPRODUCER = "DocumentProducer";
        public const string DOCUMENTCREATOR = "DocumentCreator";
    }

    public static class XLSX
    {
        public const string USENATIVEPAGEHEADER = "UseNativePageHeader";
        public const string USENATIVEPAGEFOOTER = "UseNativePageFooter";
        public const string SHOWGRIDLINES = "ShowGridlines";
    }
}

public static class TelerikRenderingExtension

{

public const string PDF = "PDF";

public const string XLSX = "XLSX";

}

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. 

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.

• Actual Value: 1469
• Displayed Text: 1,469
• Expected Search Behavior: Searching for "1469" should highlight "1,469".
  
  
  

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.

In the Standalone Report Designer File menu, please add the shortcuts next to menu items, like Ctrl + S for Save and  Ctrl+Shift+S for Save All.

I changed several reports and then wanted to know how to save all reports at once.

When I have multiple reports open in the Standalone Report Designer, I am not able to rearrange/reorder them.

Refer to the tab behavior in Visual Studio, where you can drag one tab and move it to be in front of another tab.

At the moment it's only possible to have your reports in old-fashioned projects.

It should be possible to add/design reports to SDK-style projects. That should work no matter what target framework is (.NET Core, .NET Standard or .NET Framework).

While customising templates/CSS, I noticed the .trv-parameters-wrapper div as follows:

<div tabindex="300" class="trv-parameters-wrapper" aria-label="Parameters area. Contains 4 parameters.">
<div class="trv-parameter-container k-card"></div>
</div>

I’m working on a project that requires generating Section 508-compliant PDFs, and I’m using Telerik Reporting to build the accessible reports. However, I’ve run into a problem with how screen readers—specifically NVDA—are interpreting table content.

In my report’s table, some values like 12/01/2023 aren’t being read as dates, and values like (192,340.00)—which represent negative numbers—aren’t being interpreted as “negative” or addressing the parenthesis.