I'm trying to create a PDF report that contains some user-entered text. I'm finding that if the text contains a tab in it somewhere AND if there are no tabs prior to the first line break, the text is rendered incorrectly on the PDF: 1) tabs seem to be rendered as spaces; 2) the whole text appears to be double-spaced; and 3) not all of the text appears on the pdf -- the end of the text seems to be getting cut off (which is a critical problem for our users).
I'm guessing that for #3, jasperreports tries to calculate how tall to make the stretched textbox based on if it were single-spaced. Since it's suddenly double-spacing it, then only roughly half (or less) of the text is actually displayed on the PDF.
Does anyone know of any workarounds for this issue? I've added a comment to tracker #5845 (http://community.jaspersoft.com/jasperreports-library/issues/5845) with these details. See that ticket for some test scenarios.
For now, we're going to prevent our users from entering tabs into their text by automatically converting tabs to spaces. (Which is a bummer. They'd like to be able to use tabs!) At least this avoids the problem altogether.
If at least one tab appears prior to the first line break, then all of the text appears correctly on the PDF. So, I'm alternatively looking into possibly injecting a tab at the end of the first line of any user-text that has a newline before any tabs. In some cases, I suppose that would cause the first line to wrap strangely because of the added tab. But it would at least prevent critical user-data from being cut off of the PDF; and in some situations, it might not even have a visible affect.
Can anyone think of a better work-around?
I'm primarily using jasperreports-4.7.0.jar, but I've tested it with jasperreports-5.0.0.jar as well, and see the same result.
-----------------------------
Edit #1: See the attached adminnotereportdesign.jrxml. This is a subreport that we're using that sometimes shows and sometimes doesn't show the bug (given the right values for $F{displaySubjective} --see the example text I've uploaded for tracker ticket #5845).
-----------------------------
Edit #2: See also the attached paragraphsreport.jrxml and its resulting pdf file. I hand-modified the existing ParagraphsReport.jrxml that's in the jasperreports-5.0.1\demo\samples\paragraphs\reports folder.
- Log in or register to post comments
4 Answers:
In case if this will help anyone else... my team has decided that our current temporary work-around will be to inject a tab character into the users' text in situations which would cause the bug to appear. For us, that's a javascript change. For any multi-line textbox that our users can put text into, in our custom onBlur method, we'll add this javascript:
/* Make sure we match the ENTIRE string: from ^ to $. Also, [\s\S] matches any character including new lines. */
var regEx = /^[^\r\n\t]*\r\n[\s\S]*\t[\s\S]*$/;
if (evt.target.value.match(regEx) != null){
/* Inject a tab before the first line break (only). */
evt.target.value = evt.target.value.replace(/\r\n/, "\t\r\n");
}
The tab-before-a-line-break trick seems to magically make the report work, so our users will be able to use tabs in their text.
We're still hopeful for a real bug-fix in jasperreports soon, but for the short term, we think this might be a tolerable hack/solution...
Hi,
Can you try use firstLineIndent="1" for the text element containing the tabs? You could set this attribute on a report style definition associated with the text field.
Thanks,
Teodor
Teodor, Thanks for your attention to the problem. The short answer is Yes. In the demo ParagraphsReport.jrxml, if I remove the style tag from the top of the .jrxml, I see the bug in the resulting pdf output. But if I replace the <style> tag in the demo with this: <style name="dede" fontName="DejaVu Sans" isDefault="true"> <paragraph firstLineIndent="1"/> </style> , it lets me use tabs in that PDF. However, the long answer is No because in my company's situation, we have 400+ reports and many of them are very specific about the width of the labels and textboxes. Shifting the text to the right by one pixel is unfortunately too problematic. (Both because many labels and textboxes will get their text cut off or wrapped prematurely, and also because there are simply too many reports to fix and test and we worry that we'd miss one if we implement a manual fix like this (especially going forward with new reports - if one of us on the team forgets to add the hack). We'd really appreciate a true bug-fix in the jasperreports-x.y.z.jar, since I can't seem to think of a completely invisible (no added pixels or shifted text) and generic (easily deployed to all 400+ of our reports) work-around.... Thanks, Sarah
Great! Thanks. :)
Hi,
I'm facing the same problem. I'm primarily using jasperreports-4.5.0.jar, I don't know which fulture version will fix the issue, and i'm current in the emergency, although the next fixed version will come out soon, I also can't upgrade it for many reasones. So to fixe it through modifying the jasperreports's source code will be the best way for me. Could anyone advice me which code block relavant to the issue? Any help will be apreciated.
