jasper text field getting truncated
Asked Answered
O

5

17

I'm having a font issue with my jasper report where one of my more wordy text fields (the last one in a detail band) is getting cut off in the PDF and PDF Preview but not in the Internal Preview.

e.g.

Internal Preview:

Here is a fake description. It fits
perfectly, fitting just in the lines.

PDF Preview

Here is a fake description. It 
fits perfectly, fitting just in the

Jasper is (seemingly) using some algorithm to figure out how tall the field should be, my text is barely fitting, then when the PDF is generated the text wraps and disappears on the next line.

I'm not using custom fonts (just the default/implicit "SansSerif"), and not using any custom styles beyond bold/italic. This behavior is demonstrable in both iReport's PDF Preview and my code's generated PDF on Windows and MacOS (Linux likely still has the issue, but my example text didn't exhibit the behavior on Ubuntu).

I've played with Stretch Type, Position Type, and Stretch with Overflow, as well as moved this text field to its own band but none fixes this bug (and several of them cause others).

I've had luck changing the font to the other built-in fonts, but this just tells me my example doesn't work for that particular font, not that I've fixed the bug.

Any tips would be greatly appreciated.

Update 1

I tried upgrading from Jasper Reports 5.2.0 to 6.2.0 and Jasper Fonts 4.0.0 to 6.0.0... no change.

Update 2

Tried editing my src/main/resources/jasperreports_extension.properties and adding

net.sf.jasperreports.export.pdf.force.linebreak.policy=true

... no change.

(Notably though in my use-case I can't use isStretchWithOverflow="true", so this may be why it didn't work.)

Update 3

I tried embedding the font by editing src/main/resources/jasperreports_extension.xml and adding:

net.sf.jasperreports.extension.registry.factory.fonts=net.sf.jasperreports.engine.fonts.SimpleFontExtensionsRegistryFactory
net.sf.jasperreports.extension.simple.font.families.arialFontFamily=fonts/customFontFamilies.xml

customFontFamilies.xml:

<?xml version="1.0" encoding="UTF-8"?>
<fontFamilies>
 <fontFamily name="ArialEM">
   <normal><![CDATA[fonts/Arial/Arial.ttf]]></normal>
   <bold><![CDATA[fonts/Arial/Arial Bold.ttf]]></bold>
   <italic><![CDATA[fonts/Arial/Arial Italic.ttf]]></italic>
   <boldItalic><![CDATA[fonts/Arial/Arial Bold Italic.ttf]]>/boldItalic>
   <pdfEncoding><![CDATA[Cp1252]]></pdfEncoding>
   <pdfEmbedded><![CDATA[true]]></pdfEmbedded>
 </fontFamily>
</fontFamilies>

... no dice. (Though this did help with an issue where Firefox's PDF renderer wouldn't render bold fonts.)

Update 4

I noticed that in all the test-cases I was able to create that the first line was blank, so I changed the particular cell to be vertical-align top, which worked, but of course made that one cell misalign when there wasn't much text in it.

Scrapped that as a solution, but may work for someone.

Update 5

At this point hopefully it's clear I've tried the "real" solutions and watched them all die a horrible death. Thus, we enter the realm of the hack solution. First I tried @wmmci's solution, but his answer changes the height of my box (due to it being dynamically calculated by Dynamic Jasper). I noticed that all of the examples I could create involved intra-word periods in the string, e.g. "foo...bar". That might not be your case, but it was for me. So I injected a "hair space" (&#8202;) after intra-word spaces.

This is obviously not a real solution, just a temporary work-around until I'm able to find more examples of the bug.

Update 6

I checked and I don't have @KarolisŠarapnickis's issue with the printOrder. Ah well. I shall soldier on. ;-)

Outlier answered 21/11, 2013 at 15:41 Comment(2)
Did you find a solution for this problem? I have the same issue and it is so annoying... it seems like jasper can't calculate the max number of characters if it is a input data in bold and then it cuts the leftover at export to PDFAlloplasm
For future reference, users with this problem should check that font-extensions are used correctlyPearse
T
19

I had same issue and I tried all possible configurations - didn't work. Finally as a workaround I appended a new line character to the field and it worked. Something like this: $F{description} + "\n"

Threecornered answered 24/2, 2014 at 18:39 Comment(5)
Any expandable textarea is going to have this problem, so you'd need to add the carriage return to everything. Further, it's also going to affect field heights. Still... It is a viable workaround for the desperate (which arguably I am).Outlier
Worked for me too. In our case the jasperprint is generated on a linux server and displayed on a windows client. My guess is that it uses linux fonts of a slightly smaller size to compute the required space, and then when showing it on windows, the windows font doesn't fit in.Amblyoscope
Up-voting - I spent a lot of time trying and searching before I came upon this solution,Jailer
This workaround worked for us. However we did get unwanted line breaks at the bottom of some fields. I believe it maybe something to do with our pdf font being Helvetica and our jasper font being arial. Apparently pdf font is deprecated so will investigate a better fix. Possibly using font-extensions.Storfer
this worked for me in some cases, but not in some other...I've used Tibco Jaspersoft 6.3.0Arkwright
I
1

Had the same issues with text being truncated and nothing seemed to work. luckily I found out that my root xml element had the following attribute:

printOrder="Horizontal"

Removing it solved my issues.

Inspect answered 3/11, 2015 at 13:51 Comment(1)
In my case, I still have this issue but don't have printOrder="Horizontal" in my JRXML file's root node. Hopefully this will help someone out there, though.Outlier
H
1

Well, i'm not sure if you're struggeling with the exact same problem i was. But my solution was setting the property "net.sf.jasperreports.print.keep.full.text" of the field to "true".

Hemingway answered 3/12, 2018 at 13:16 Comment(0)
N
0

In my case, I had really long text in a single text field. Adding a line break would solve the issue for some cells, but not for the really long ones that spanned pages. To finally solve it, I had to set the text field to stretch to RELATIVE_TO_BAND_HEIGHT. Previously, it was set to RELATIVE_TO_TALLEST_OBJECT. My guess is that, RELATIVE_TO_TALLEST_OBJECT was being calculated incorrectly (lower than needed).

This did the trick:

textField.setStretchType( StretchTypeEnum.RELATIVE_TO_BAND_HEIGHT );
Natika answered 19/5, 2016 at 19:25 Comment(0)
F
0

Seems like the only working solution is to put some text formating signs as @wmmcii said. Then another text renderer is used (discused here). However the new line \n is not ideal, because there is unwanted influence to the output doc. Better solution seems to put tab sign \t to the end of the line. To avoid additional problems when using Horizontal Alignment = Justified, put also a space prior to tab sign. For example:

$F{my_text} + " \t"
Fractionate answered 18/8, 2021 at 14:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.