tabs in text mess up PDF output

[sarahjd]

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.1demosamplesparagraphsreports folder.

[teodord]

Hi,

 

Please send us some sample report showing the problem. Also, try take a look at the sample shipped with the JR distro under the /demo/samples/paragraph folder where text with tabs is rendered.

 

I hope this helps.

Teodor

 

[sarahjd]

Hi, Teodor. Thanks for your response and your idea to look at the demo. I did some comparing to my own reports, and found out that I can reproduce the issue in the sample ParagraphsReport.jrxml if I delete the default "dede" style (or just delete its paragraph tag), or if I set all of the dede's paragraph tag's values to zeros (leftIndent="0" rightIndent="0" firstLineIndent="0")

 

I seem to be able to make the issue disappear in one of my own reports by adding a default style and setting BOTH the tabStopWidth to a value greater than zero AND either the leftIndent or the rightIndent to a value greater than zero. (So something like this: paragraph leftIndent="1" tabStopWidth="40") I don't really want anything indented, but if I only specify the tabStopWidth, it doesn't fix the issue.

 

I'll keep looking at this, and let you know if I figure anything else out.

 

Thanks!

~Sarah

[sarahjd]

It looks like if I specify those two paragraph values (paragraph rightIndent="1" tabStopWidth="40") inside an individual textElement (and not as part of the report's default style), it "fixes" the issue as well (just for that text box, though).

[sarahjd]

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, [sS] matches any character including new lines. */
var regEx = /^[^rnt]*rn[sS]*t[sS]*$/;
if (evt.target.value.match(regEx) != null){
    /* Inject a tab before the first line break (only). */
    evt.target.value = evt.target.value.replace(/rn/, "trn");
}

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...

[sarahjd]

Teodor, I uploaded a jrxml that shows the problem (in the right scenario). In case if it helps you track down the bug.

[sarahjd]

After evaluating this further, we've noticed that if the users' text is so long that it starts a new report page, then the bug reappears. :( So we may need to go back to converting all tabs to spaces to prevent the issue.

[teodord]

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

 

[sarahjd]

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 , 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

[teodord]

Hi, Sarah

 

Thanks for testing the reports with the proposed modification. I'm not saying this is the solution. It just helped us identify the problem and solve it properly. We'll let you know when ready.

 

Thanks,

Teodor

 

[raindy]

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.

[sarahjd]

Great! Thanks. :)

[teodord]

Hi,

JasperReports 5.0.4 released recently addresses this issue. Let me know if you tried it.

Thanks,
Teodor