Completed
Last Updated: 02 Oct 2026 11:23 by ADMIN
Release 2026.3.923 (2026 Q3)
Tim
Created on: 03 Sep 2026 11:40
Category: PdfProcessing
Type: Bug Report
1
PdfProcessing: Wrapped table cell text is incorrectly split by hyphens ("-")

Wrapped table cell text is incorrectly split by hyphens ("-").

This is a regression introduced in version 2026.3.826. Use an older version to avoid this issue.

4 comments
ADMIN
Yoan
Posted on: 02 Oct 2026 11:23

Hello Tim,

Thank you for the detailed feedback and for confirming that the fix in 2026.3.923 resolves the original mid-word text wrapping issue. We're glad to hear that the behavior is now back to what you were seeing in 2026.3.810 for that scenario.

At the same time, we're sorry to hear that you're still encountering a related issue in your production reports. We appreciate you taking the time to investigate the behavior and provide such a thorough description of the remaining problem.

We also appreciate the effort you've put into preparing a reproducible sample and the side-by-side comparisons between the different versions. Unfortunately, I'm not able to see the updated project attachment you referenced in your message. Could you please reattach the sample so we can review it?

Additionally, we would recommend opening a separate support ticket for this issue. Although it appears to be related to the original regression, it represents a distinct behavior that will be easier to track, investigate, and communicate about in its own thread. Keeping the discussions separate also helps avoid very long conversations where multiple issues become mixed together, which can sometimes lead to confusion during the investigation process.

One other important point is that the current discussion is attached to a public Feedback Portal item. Any files or other resources shared here may be publicly visible. For that reason as well, we recommend opening a new support ticket and attaching the project there, where the files can be reviewed privately by our team.

Once you've created the new ticket and attached the sample, we'll be happy to take a closer look at the remaining behavior and continue the investigation there.

Thank you again for the detailed report and for helping us improve the product.

Regards,
Yoan
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.

Tim
Posted on: 28 Sep 2026 17:33
Hi,

Thank you for the fix in 2026.3.923 — we've confirmed it resolves the mid-word body-text wrapping we originally reported (a FixedWidth table cell's text now breaks cleanly at word/hyphen boundaries again, matching the behavior we had on 2026.3.810 before the regression was introduced in 2026.3.826).

However, after upgrading and testing against one of our production reports, we found that 2026.3.923 does not fully fix the underlying issue. There's a second symptom of the same FixedWidth column-shrink/text-measurement regression that is still present, identical to 2026.3.826:

Issue: When a FixedWidth table's proportional column shrink leaves a column narrower than its label/value, and that text has no word-break opportunity (e.g. a short header like "Bkt" or "Date", or a short data value like a 2-character code or a 4-digit year), the text does not wrap on any reasonable boundary — it wraps one character per line, stacking the text vertically inside the cell. This inflates that row's height 2–3x, which cascades through the entire table: more pages, and (in our case) misaligned totals on the pages that follow.

This is present identically on 2026.3.826 and 2026.3.923, and absent on 2026.3.810 — same root cause as the original ticket (the FixedWidth shrink math), just a different visible failure mode that your fix didn't cover.

Repro attached (updated version of the project from the original ticket): a HeaderWrapRepro scenario that reproduces this with the exact column widths, header labels, font, and page geometry from our production report, plus 15 rows of representative (synthetic, non-confidential) data so the row-height cascade is visible, not just an isolated header row. Rendered output for 2026.3.810 / 2026.3.826 / 2026.3.923 is included in sample-output/ for side-by-side comparison — 826 and 923 are pixel-identical to each other and both broken; 810 is correct.

Request: Given that a release marked "Completed" for the original regression shipped with this closely-related regression still in it, could you add automated regression testing around FixedWidth table layout/text-measurement to your release process — ideally something that renders known-good fixture tables (including ones with narrow columns and short, unbreakable text) and diffs the output against a previous baseline before a release goes out? This class of layout bug is highly disruptive for us since it's silent (no exception, just visibly corrupted output) and affects every report built on RadFixedDocument/Table/TableCell with TableLayoutType.FixedWidth. Catching it with a build-time regression suite rather than downstream customer reports would help avoid this in future releases.

Happy to share more of our internal test output or answer any questions about the repro. Thanks for looking into this.
ADMIN
Yoan
Posted on: 14 Sep 2026 14:58

Hello Tim,

We completely understand the setbacks and inconvenience that regressions can cause, especially when they impact an important part of a customer's workflow. We take regressions very seriously, and our process specifically treats them with the highest priority to ensure they are addressed as quickly as possible.

With that in mind, I would like to inform you that the issue is already under development, and we plan to introduce the fix in our next Document Processing release.

We also agree that it is important for customers to have publicly available information about known regressions. This is one of the main purposes of our Public Feedback Portal, where reported issues are tracked and logged so that customers can stay informed about their status and any relevant workarounds or affected versions.

I have gone ahead and updated the public page for the reported issue to explicitly flag it as a regression and, importantly, to identify the exact version in which the regression was introduced. This gives customers visibility into the issue and allows them to make an informed decision about which version to use if they need to avoid it.

In parallel, the regression itself is being handled through our normal regression process, where it receives the highest priority. We appreciate you bringing this to our attention and understand the importance of getting the fix in place as soon as possible.

Regards,
Yoan
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.

Tim
Posted on: 10 Sep 2026 14:21
It would be helpful to notify uses not to upgrade until this is fixed.  There is no error thrown just garbage PDF output in the document.