I thought I'd add some observations here. I found this thread while
googling for a solution to my own problem. My problem is that if I
generate a JasperPrint output on our Linux server (running Java 1.5),
serialize that JasperPrint to a Swing client running on a Windows XP
box, and display that JasperPrint using the provided Swing viewer, then
the "stretch" areas will almost always chop off the last line of text.
I believe this is because isStretchOnOverflow is something that is
computed at report fill time and a hardcoded size is placed into the
final JasperPrint (the "hardcoded" size having been computed using the
font installed on the Linux box). So, if my "stretch" area needs to
stretch in order to show the last two lines of text, for example, it
won't quite be big enough to hold both lines of text when viewed on a
windows box. It appears that the Swing viewer is not rendering the last
line of text unless it is completely containable within the alloted
area. Now, if I then "export to PDF" from the Swing rich client, the
resulting PDF (which was generated from the Swing rich client itself,
not the server) will properly show the text!
If I understand this thread correctly, then one solution would be to
copy the Windows font over onto our Linux server and point the JVM to
it. This is, of course, the most accurate solution. But for those who
don't have access to the font or don't want to deal with any legal
ramifications of this option, I wonder if a "fudge" factor could be
configured? Something along the lines of a multiplier by which the
Jasper fill engine should multiple the computed height of each line of
text (say 1.05, for example). This could be configured at runtime by
the system, and would default to 1.0 so as to be 100% compatible with
current behavior. I realize that such a fudge factor is really a quick
and dirty hack, but it could be a useful crutch for those who don't want
to copy a font.
What do you think?
- Andy
Chris Edwards wrote:
John,
Thank you very much!
Adding JAVA_FONTS and associated fonts worked like a charm. Thank you
so much for your time and help with this. Great explanation too (and
easier than modifying font.properties...)
Thanks again.
John Bindel wrote:
The tag used tells the client platform which font to use. On the
client machine, a font that is closest to the desired font (e.g., arial)
is chosen when the PDF is rendered. What I have seen happen on Linux
is that the Lucida font (not Verdana as I accidently wrote below), does
not have the same shape. If you copy the Arial font files (or FreeSans)
and the Lucida font to some directory accessible by the machine creating
the PDF, AND set the environment variable JAVA_FONTS to point to that
directory, this should allow the JVM running on Linux to use a better
font than the Lucida font it has.
When JasperReports generates the PDF, it first creates a JasperPrint
object, and the sizes of all fields are determined when the JasperPrint
object is created. JasperReports uses the AWT to figure out how much
space is needed to render some particular piece of text, but when the
PDF is displayed, X or Windows uses all of its available fonts to render
the text, so the size of the text at client render time is not
necessarily the size that JasperReports thought it was when it asked the
JVM and AWT for the size.
Now the problems I have had with this were that my JVM and AWT were
allocating too much space for the text that appeared, and when I
generated the PDF on Linux, there would be extra vertical space in the
report output, but it was perfect when the PDF was generated by Windows.
It could be that when you generate the report on Linux, JasperReports
doesn't think there is enough space, though I'm not sure why it wouldn't
just be wrapping the text. Does it appear that your element
positions are
floating at all? Are the text boxes floating at all? Elements will
float only if they do not normally overlap. E.g., If last_name is shown
to the right of first_name, then the last_name x position must be
specified to be greater than or equal to first_name.x +
first_name.width.
On Tue, Feb 21, 2006 at 01:48:13PM -0600, Chris Edwards wrote:
John,
Thank you for the insight.
Isn't the PDF font specified by the "pdfFontName" attribute of the
"font" tag? Changing that attribute to other fonts doesn't work either.
Thanks again.
John Bindel wrote:
If you install Microsoft's Arial font in your Java VM, the rendering
should work much better. The JVM ships only with the Verdana font,
and
it does not seem to have the same font metrics as the Arial font you
are using in your PDF.
You may also try the FreeSans font if you don't wish to install Arial.
On Tue, Feb 21, 2006 at 07:51:36AM -0600, Chris Edwards wrote:
Please help,
1. uname -a gives:
Linux asg-rh-webdev 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT
2005
i686 i686 i386 GNU/Linux
2. JDK 1.5.0_04
3. JasperReports
