Unplanned
Last Updated: 12 Mar 2026 21:07 by Simon
Warren Bailey
Created on: 17 Dec 2018 22:37
Category: Reporting
Type: Bug Report
2
Numbered list that spans two pages restarts at (1) when exported to MS Word.

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.

2 comments
Simon
Posted on: 12 Mar 2026 21:07

Bumping this issue - still present in 2025 and a serious gap in a core feature combination

 

We are still hitting this exact bug today. The combination of HtmlTextBox + Word export is marketed as a first-class Telerik Reporting capability, yet a fundamental HTML construct - a simple ordered list - renders incorrectly in both split scenarios described in the original report.

 

To be direct about the impact: this is not an edge case. Ordered lists that span pages are routine in any compliance, legal, or governance document. Our use case is generating reports for local government - documents where numbering accuracy has legal significance. A list that silently restarts at (1) on a new page is not just a cosmetic defect; it changes the meaning of the document.

 

We also want to flag that the PDF renderer has a related but separate issue: when an HtmlTextBox containing a long list crosses a page boundary in PDF output, the content is cut at the pixel-level page margin rather than at a text line boundary, producing a mid-glyph split. We have a separate support ticket open for that.

 

Between the two issues, neither of the two primary export formats - PDF or Word - renders HtmlTextBox list content correctly across page boundaries. This effectively means HtmlTextBox cannot be used reliably for multi-page list content in production reports, which significantly undermines its usefulness.

 

The original ticket is now six years old with no fix. We would strongly urge Telerik to prioritise this. The HtmlTextBox is clearly intended to handle rich content; page boundaries are not an unusual condition. Correct list continuation across pages is baseline expected behaviour for any document renderer.

 

We have added our vote. Please action this.

ADMIN
Ivan Hristov
Posted on: 27 Dec 2018 09:38
Hi Warren,

This is a known issue with Telerik Reporting Word rendering. HTML ordered list restarts the numbering after the page break when exported to Word formats.
This issue is already logged into our system for further investigation and improvement.

I would like to thank you for logging it into our feedback portal, so the other users could vote for it, thus changing its implementation priority. I also noticed that my colleague had answered to you about the same inquiry in a previous support thread (#988205). The same suggestions are still valid and I hope they would work for the current scenario until a fix is available.

Regards,
Ivan Hristov
Progress Telerik
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items