Jasper & IReport cortando texto

[tRuNkSnEt]

Olá gente,

Bom, estou com um problema que ja muito quebrei a cabeça para resolver e não consigo. Tenho um relatório (pdf) que todo seu detail é um campo de texto que as vezes pode receber um texto de várias páginas. Acontece que no final das páginas ele está cortando texto, ora uma palavra ora uma linha inteira. Alguem tem alguma idéia de como resolver esse problema?

[AdrianoPalm]

Você recebe este texto em uma text field né?

A opção Stretch when overflow, desta txt, tá true ou false?

[tRuNkSnEt]

Está marcada como true, senão nao consigo expandir de acordo com o texto que pode variar. As vezes é o seguinte. Tenho um relatório com 3 páginas de texto. Entre a 1a e 2a página, bem na troca de página o jasper está cortando o texto e continuando na próxima página faltando palavras. Pelo que vi pela net existem várias pessoas com este problema porém ninguém conseguiu a solução.

[AdrianoPalm]

Justamente, por isso achei que tava marcada como false… pois o texto está sendo cortado.

Outro teste interessante: Aumente bem o tamanho do texfield e teste.

[tRuNkSnEt]

Também foi feito. O jasper tem uma altura de 802pixels para uma folha padrão A4 então eu peguei o header e o footer somei e subratai de 802. O resto que sobrou botei no detail e expandi meu campo de texto até o limete para ficar bem justo em uma A4. Fiz testes de impressão ficou certo. Porém continua cortando.

[AdrianoPalm]

Oxi, que trem estranho!!!

Já testou para ver se o valor passado pro relatório tá completo?

[tRuNkSnEt]

Sim … Eu uso uma JRBeanCollectionDataSource então antes de passar minha colection para está classe eu faço um forEach para verificar. E está certo.

Muito estranho, pelo que andei lendo pelo forum deles isso pode ser possível por umas regras de measure que tem na fonte. Várias pessoas reclamando.

[tRuNkSnEt]

Andei observando que existem umas propriedades custom que pode ser aplicada aos campos texto, são estas:

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.

Consigo fazer a tradução destas propriedades claramente porém não entendo como aplica-las. Alguem tem alguma experiencia com estas propriedades?

[AdrianoPalm]

Dê uma olhada aqui e vê se ajuda:

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

[tRuNkSnEt]

[quote=AdrianoPalm]Dê uma olhada aqui e vê se ajuda:

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

Muito bom, vou testar. Acabei de achar essa maravilhosa dica, Veja:

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.

Uma das questões é justamente o que você colocou naquele link (o LineBreak_Policy) é a outra pode ser incompatibilidade de fonte. Então deixa eu entender. No meu relatório tem fonteName = SanSerif (default) e o pdfFontName = Helvetica (também Default) isso quer dizer que essas duas fontes podem não combinar? As duas não são reconhecidas pelo java.awt.font (que por sinal eu odeio)? Como determinar que fonte equivale a qual fonte?

Você saberia me dar alguns detalhes sobre como o ireport trabalha com essas fontes?

[AdrianoPalm]

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

[tRuNkSnEt]

[quote=AdrianoPalm]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???

[/quote]

Sim, problema é que é muito difícil fazer um caso de testes para esse problema. É uma coisa muito invariável, as vezes eu faço uma modificação pequena e o texto se ajusta mais dai quando uso outro texto não funciona.
Então tenho que entender bem a lógica para fugir o máximo possível dessas pegadinhas. Os pdfs aceitam poucas fontes e a unica equivalente em ambos é a Time New Roma. Vou adicionar também a LineBreak_policy e fazer vários testes para ver no que vai dar.

[rogerionj]

Estava passando pelo mesmo problema,

No ireport a fonte estava Times New Roman - Italica, e no pdf Times-Italic,

a quebra de linha estava cortando a frase.

Botei a fonte do iReport - JVM Arial e a PDF continuou Times-Italic

Funcionou perfeitamente

[araujoGo]

Colegas, como chegaram a resolução do problema? Estive pesquisando bastante e nada de achar uma solução.