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.

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).

Currently, the GetDesignerResource endpoint of the Web Report Designer service is case-insensitive, which can lead to issues if the URL is made lowercase at some point, such as by a URL rewrite rule, or similar scenarios.

For example, the following reference to the Web Report Designer script will load return the file:

<script src="api/reportdesigner/designerresources/js/webReportDesigner"></script>

But if lowercase is used, for example, like this:

<script src="api/reportdesigner/designerresources/js/webreportdesigner"></script>

The request will return a 404(Not Found) response.

Using the text-indent CSS setting results in part of the text on the first line being cut off:

I cannot localize the messages of the Angular and React report viewers using the suggested approaches:

• Angular Report Viewer Localization - Telerik Reporting
• Localizing the React Report Viewer - Telerik Reporting

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.

If I try to drag & drop fields in the Standalone Report Designer for .NET, it does not allow me to paste the field, and the icon changes, indicating that the action is not allowed.

On the other hand, I can drag & drop the fields as expected when using the Standalone Report Designer for .NET Framework.

On export to MS Word, a numbered list that spans two pages restarts at (1) on the second page. Instead, the numbered list should continue numbering from the first page. 

For example, if a list has five items and the fourth item starts on a new page, when I export the report to MS Word, the first three items are numbered (1), (2), and (3), and the last two items are numbered (1) and (2) again.  The last two items should be numbered (4) and (5).

In addition, if an item in a numbered list splits between two pages, the item is numbered twice: once at the beginning of the item and again on the first line that appears on the next page. The line at the top of the second page is numbered (1). This second number should not appear.

The attached file shows both these issues.

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 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

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.

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.

When using the SqlDataSource component with a stored procedure that has an IF-ELSE condition which selects a different set of columns depending on whether the condition is true or false, the returned data schema is always as if the condition is evaluated to true.

While the schema is wrong, if I manually type the fields, at runtime, they get resolved correctly but it is inconvenient.

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.

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 want to set the Table ColumnWidth to a particular value in the Properties of the Web Report Designer. There is no property ColumnWidth as in the Desktop designers, and I tried to set the Size.Width, which is available.

When I increased the Width from the Properties, in design time, there is no change in the column width, only dashed borders indicating the new size when selecting the corresponding TextBoxes. In runtime, though, the new size is respected.

The inconsistency repeats even when I open the saved report in another browser or through another application, hence this is not a caching issue.