Introduction
I recently hit a really specific edge case while building a PDF feature for our SAP UI5 app. We were using pdfmake, and honestly, everything looked great during standard testing. But then the backend sent over some real-world data—specifically these massive, continuous strings of text—and the whole layout just fell apart.
Even though we had set fixed column widths, the table completely ignored them. The text refused to wrap, spilled right over the borders, and basically ruined the document structure. It’s one of those issues you don’t usually catch until you throw messy, non-standard data at your code. In this post, I’ll break down exactly why pdfmake struggles with this and the simple workaround we found to keep the layout intact without changing how the text looks.
Problem Description
We get a specific edge case while building a PDF feature in our SAP UI5 app using pdfmake(pdf playground). Everything looked fine until the backend sent over a massive string of text, which is mix of special characters. Even though we had fixed-width columns, the table ignored them—text wouldn’t wrap, it spilled over the cell borders, and basically broke the whole layout.
The issue became easier to reproduce when the input text had:
Very long continuous strings
No spaces
A lot of special characters
Example:
ssssssssss@@@@@@@@@@@@@@@uuuuuuuuuuuuuiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
Even noWrap: false was already set, it didn’t help.
The reason became evident after studying the text analyzing logic of pdfmake.
When the text consists of a single, continuous word, pdfmake determines the whole length of the string from considering it as a single, unbreakable unit.
Both of the font issue and the PDFmake bug aren’t the root cause of this. Wrap points can’t be put into continuous text; additionally fonts like Roboto or NotoSans only aid in character rendering.
This will fix when we insert invisible wrap points into the string before sending it to pdfmake.
We used a zero-width space character that is (u200B), which is invisible for human eye but allows PDF engines to wrap text safely
Code:
function safeBreak(str) {
return (str || ”).replace(/(.{1})/g, “$1u200B”);
}
This will not change the text looks in the PDF, but it gives pdfmake to break point to respect the table width and wrap content correctly.
The user can view the PDF in exactly the same manner. So as for pdfmake is properly wrap the text so the table width, this simply adds a few break points.
This turned out to be a invisible (for human eye) edge case when generating PDFs with dynamic data. Adding zero-width spaces solved the problem without affecting visible output.
Before Applying the Fix
After Applying the Fix
Try the Working Demo
If you want to see how this project, we put together a complete SAP UI5 sample app. It covers the basic pdfmake setup and shows exactly how to handle those long strings inside table cells so they don’t break your layout. You can check out the code here: PDF_SAP
Conclusion
Long, unbroken strings are definitely one of those hidden edges when you’re generating PDFs with dynamic data. Since pdfmake needs explicit breakpoints to know when to wrap a line, it will break your table layout if it doesn’t find them.
We went with the zero-width space (u200B) in the end because, frankly, it just works. It makes the text wrap properly so the table widths doesn’t get destroyed, but visually, you can’t tell the difference, this annoying bug can be easily and safely fixed.
IntroductionI recently hit a really specific edge case while building a PDF feature for our SAP UI5 app. We were using pdfmake, and honestly, everything looked great during standard testing. But then the backend sent over some real-world data—specifically these massive, continuous strings of text—and the whole layout just fell apart.Even though we had set fixed column widths, the table completely ignored them. The text refused to wrap, spilled right over the borders, and basically ruined the document structure. It’s one of those issues you don’t usually catch until you throw messy, non-standard data at your code. In this post, I’ll break down exactly why pdfmake struggles with this and the simple workaround we found to keep the layout intact without changing how the text looks.Problem DescriptionWe get a specific edge case while building a PDF feature in our SAP UI5 app using pdfmake(pdf playground). Everything looked fine until the backend sent over a massive string of text, which is mix of special characters. Even though we had fixed-width columns, the table ignored them—text wouldn’t wrap, it spilled over the cell borders, and basically broke the whole layout.The issue became easier to reproduce when the input text had: Very long continuous strings No spaces A lot of special charactersExample:ssssssssss@@@@@@@@@@@@@@@uuuuuuuuuuuuuiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiEven noWrap: false was already set, it didn’t help. The reason became evident after studying the text analyzing logic of pdfmake.When the text consists of a single, continuous word, pdfmake determines the whole length of the string from considering it as a single, unbreakable unit.Both of the font issue and the PDFmake bug aren’t the root cause of this. Wrap points can’t be put into continuous text; additionally fonts like Roboto or NotoSans only aid in character rendering.This will fix when we insert invisible wrap points into the string before sending it to pdfmake.We used a zero-width space character that is (u200B), which is invisible for human eye but allows PDF engines to wrap text safelyCode:function safeBreak(str) {
return (str || ”).replace(/(.{1})/g, “$1u200B”);
} This will not change the text looks in the PDF, but it gives pdfmake to break point to respect the table width and wrap content correctly.The user can view the PDF in exactly the same manner. So as for pdfmake is properly wrap the text so the table width, this simply adds a few break points.This turned out to be a invisible (for human eye) edge case when generating PDFs with dynamic data. Adding zero-width spaces solved the problem without affecting visible output.Before Applying the FixAfter Applying the FixTry the Working DemoIf you want to see how this project, we put together a complete SAP UI5 sample app. It covers the basic pdfmake setup and shows exactly how to handle those long strings inside table cells so they don’t break your layout. You can check out the code here: PDF_SAP ConclusionLong, unbroken strings are definitely one of those hidden edges when you’re generating PDFs with dynamic data. Since pdfmake needs explicit breakpoints to know when to wrap a line, it will break your table layout if it doesn’t find them.We went with the zero-width space (u200B) in the end because, frankly, it just works. It makes the text wrap properly so the table widths doesn’t get destroyed, but visually, you can’t tell the difference, this annoying bug can be easily and safely fixed. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
