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.

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

If a table-based item (Table, List, Crosstab) does not fit in a single page and needs to occupy more than one page, its bottom border is not drawn on the first page and its top border is not drawn on the second (subsequent) page. This behavior is by design and its purpose is to help the users visually distinguish the table as a single item. The table has only one top and bottom border and they are displayed at the beginning and at the end of the table, regardless how many pages the table actually occupies.

Since users might find this confusing, a table should have a property controlling this behavior. The default state of the property will preserve the current rendering. If the user explicitly sets the property, then the table will draw its top and bottom borders on every page it occupies.

If the HTML5 Report Viewer gets hidden on renderingBegin(e, args) event and shown on renderingEnd(e, args) event, its toolbar is shown, but the contents are still invisible.

Code snippet that demonstrates the issue:

$("#reportViewer1")
    .telerik_ReportViewer({
		... initialization script goes here
        renderingBegin: function (e, args) {
           $("#reportViewer1").hide();
        },
        renderingEnd: function (e, args) {
           $("#reportViewer1").show();
        }
    });

Hello, 

I currently have a WebServiceDataSource in my report using a POST Method, a Body and a Parameter for Content-Type.

However, if I try to add a second WebServiceDataSource with a Content-Type parameter it throws an error saying that the Name already exists.

See the following screenshot for a visual reference.