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

inanutshellus
  • 9,683
  • 9
  • 53
  • 71
  • 1
    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 PDF – Jesus Peralta May 31 '17 at 07:41
  • For future reference, users with this problem should check that [font-extensions](https://stackoverflow.com/documentation/jasper-reports/5773/font-extensions#t=201705312048127084075) are used correctly – Petter Friberg May 31 '17 at 20:48

5 Answers5

18

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"

wmmcii
  • 196
  • 2
  • 3
  • 1
    _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). – inanutshellus Feb 23 '16 at 15:22
  • 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. – tobi42 Apr 06 '16 at 15:28
  • Up-voting - I spent a lot of time trying and searching before I came upon this solution, – Plamen Jul 23 '19 at 20:31
  • 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. – Chris Nov 27 '19 at 12:01
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.

Karolis.sh
  • 1,618
  • 20
  • 20
  • 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. – inanutshellus Feb 23 '16 at 15:04
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".

Dr.Seltsam
  • 146
  • 1
  • 4
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 );
Dan Torrey
  • 1,379
  • 15
  • 25
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"
Dorregaray
  • 381
  • 3
  • 6