net.sf.jasperreports.print.keep.full.text

Property used to determine whether the fill process must preserve the original text for text elements that are not able to fit their entire contents. When this property is set, the engine saves the original text in the JRPrintText print text object, along with the index at which the text is to be truncated by the print object.

net.sf.jasperreports.text.truncate.at.char

Boolean property that determines whether text elements are to be truncated at the last character that fits. By default, when the entire text of a text element does not fit the element's area, the text is truncated at the last word that fits the area.

net.sf.jasperreports.text.truncate.suffix

Property whose value is used as a suffix for the truncated text. The suffix is appended to the text when truncation occurs. If the property is not defined or empty (which is the case by default), no suffix will be used when the text is truncated.

AdrianoPalm wrote:Dê uma olhada aqui e vê se ajuda:

http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=35245

Why is my text not displayed correctly in PDF?

When your PDF reports contain texts that do not stretch properly (i.e. are truncated or leave some space unused), or have improper line spacing, the probable cause is that the Java/AWT and PDF fonts used for the report text elements do not match.

The fontName attribute of a report text element is resolved to a Java/AWT font which is used at report fill time to compute several text layout attributes including how much does the element need to stretch in order to accommodate its contents, or what part of the text does fit if the element is not allowed to stretch. When the report gets exported to PDF, the text layout parameters computed at fill time are used along with a PDF font determined by the pdfFontName attribute of the text element. If the PDF font metrics are not identical to the metrics of the Java/AWT font, then the text in the PDF output might not fit entirely or might not use the entire space reserved for the text element.

Because of this, the JasperReports engine works by the contract that the Java/AWT font (specified using the fontName attribute) and the PDF font (specified using the pdfFontName attribute) resolve to the same physical font (or to fonts that have identical metrics).

One thing to play attention to is making sure that the fonts set in the report via fontName attributes are actually available in the Java VM, because AWT silently uses the default font when a specific font cannot be loaded.

When confronted with such issues it is useful to display the report in JasperViewer, as the viewer would use the same Java/AWT fonts that were involved in computing the text layout attributes (assuming that the fonts are still available in the JVM). If the report displays properly in JasperViewer, then it is very likely that the PDF fonts do not match the Java fonts.

One more possible cause of text not displaying properly in PDF (even when the fonts match) is the fact that the default AWT and PDF line breaking policies differ slightly. The solution to this issue is to instruct the PDF exporter to use the AWT line breaking policy. This is done by setting the FORCE_LINEBREAK_POLICY exporter parameter to true, or by setting the net.sf.jasperreports.export.pdf.force.linebreak.policy property to true either globally (in jasperreports.property) or at report level.

AdrianoPalm wrote:Coincidência... tava lendo exatamente esse post sobre fontes...

Vai ver é uma luz no fim do tunel....

Se funcionar, posta aê pois vai ajudar qualquer um que passar por isso, eventualmente.

Vou dar uma olhada nisso também e tentar entender esse comportamento das fontes. Por enquanto, eu iria na tentativa e erro pois não implementei nada assim, ainda.

EDIT: If the report displays properly in JasperViewer, then it is very likely that the PDF fonts do not match the Java fonts. Você testou isso????