Flow objects in tables in RTF instead of static frames

I would very much like to have this also

Hi,

 

We have refactored the RTF exporter several times in the past.

 

We are currently using frames because they allow us to preserve the layout of the document, as specified in the report template, as well as generating unicode documents.

 

The other solution we tried was to use tables. But the RTF tables had one big limitation: they did not support unicode characters. So unless you were generating reports in English, the result would have been a series of unprintable characters.

 

We are always open to contributions, if there are people more familiar with RTF specifications.

 

Thank you,

Teodor

 

Hi teodor,

 

thanks for your feedback. I have done a test with Word, using a table with three rows: ASCII, ASCII plus latin and real Unicode. Saved file as rtf and re-opened it. It works nicely.

 

There were text such as the following in the third row:

 

\u8633\'3f

 

Which means according to Wikipedia:

 

If a Unicode escape is required, the control word \u is used, followed by a 16-bit signed decimal integer giving the Unicode codepoint number. For the benefit of programs without Unicode support, this must be followed by the nearest representation of this character in the specified code page. For example, \u1576? would give the Arabic letter beh, specifying that older programs which do not have Unicode support should render it as a question mark instead.

http://en.wikipedia.org/wiki/Rich_Text_Format

 

So, in this case it is a unicode character \u8633 followed by a \3f ('?'). Please note that I used the font 'Arial Unicode' because there are only few fonts that really implement large parts of Unicode.

 

What can I do to help achieve rtf exporter with tables instead of frames?

Hi,

 

Have you checked our new DOCX exporter in JR 3.5.3?

It is a grid based exporter, so it produces tables.

If all you want is to be able to export to a Word format, then the DOCX might be for you and we can lower the priority of this tracker or even close it.

 

Thank you,

Teodor

Hi Teodor,

 

I have tested it. It is definitely a very large step in the right direction. One problem remains to allow actual use: the table rows all have an explicit height, for instance 0.5". If you then start editing the letter generated, the table row does not automatically expand. You have to play with the height (or make it autosize) to get it right.

 

I have tried "stretch with overflow", but that property does not influence the height set for the table row.

 

If you would be able to not set an explicit height for a table row (or only set it when stretch with overflow is checked), I think JasperReports would become a great generator for letters, quotes and other documents that require after-generation adaptation!

Hello Teodor,

I agree with Monty, also it would be really convenient when the Page Header band and the Page Footer band will be left out of the table and put in the page header and page footer of the word document. With the current implementation when adding or deleting rows the Page Footer (normally containing the page number) is floating around...

Kind Regards,

Michel van Klink

Hi, guys!

 

Thank you for your feedback.

 

In order to better track the issues that you mentioned, with the row height and page headers and footers, please create new trackers for the DOCX exporter, as this current issue is about RTF and I'm going to close it now, since it is highly unlikely we are going to change the RTF exporter or come up with a new one in the near future.

 

Thank you,

Teodor