Unplanned
Last Updated: 09 Apr 2026 14:08 by ADMIN
Scheduled for 2026 Q2
Simon
Created on: 13 Mar 2026 15:51
Category: Reporting
Type: Bug Report
1
The HtmlTextBox that spans 2 or more pages may cut the OL-LI elements' content vertically in the middle of the line between the pages

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.

  
2 comments
ADMIN
Dimitar
Posted on: 09 Apr 2026 14:08

Hi Simon,

Thank you for reaching out!

We are about to test a fix for this issue in the upcoming week, and we will try to include it for the 2026 Q2 release.

Whether I have good news to share on the topic or not, I will try to update you by the end of the month on the state of the item.

Thank you for your understanding!

Regards,
Dimitar
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Simon
Posted on: 04 Apr 2026 22:36
This is a production blocker for us. We use HtmlTextBox to render legally gazetted text for Australian government compliance software - numbered lists spanning page boundaries are common and the mid-line split makes PDF output unusable in a regulatory context. We are holding a module release pending a fix. The recently resolved Word export list-numbering issue shows you understand the importance of this component for document-heavy use cases - this one is equally critical. Please consider expediting.