Problems with multi-page Word tables extending off the page when rows have multi-line cells

Aspose.Words Product Family
1

I am creating a report using Jasper IReport 3.5.0 that displays data in a table that can stretch over several pages. The table displays correctly in PDF format, but when I generate a DOCX file with Aspose.Words (evaluation licence), the table descends into the bottom margin, and on to the beginning of the next page if the bottom margin is small, or if there are many table rows that contain more than one line of text.

The problem seems to be to do with the way Aspose.Words sets paragraph formatting in DOCX files: using line height, and spacing before and after paragraphs.
Aspose.Words sets the IReport cell padding using paragraph before/after spacing.
Problems occur when there are several rows with more than one line of text.

I get better results in the above scenarios if I format the table like this:

  • All cell padding set using word table / cell / margins (set to same pixel/point values)
  • Cell text: Word Paragraph before & after spacing set to 0
  • Cell text: Word paragraph indetation left & right set to 0
  • Word Paragraph line height set to: Single
  • If the IReport cell is vertically aligned centred, then set the word cell vertical alignment to be centred.

Could this (or some better way) be used to format DOCX tables so that they format more accurately when there are several rows with multiple lines in the table?
Files attached:
SUMHOURS_OUTPUTA2.docx: File produced by Aspose words from .JRPRINT file. Shows table extending into the bottom margin.
SUMHOURS_OUTPUTA2a.docx: Cells and Paragraphs on first page reformatted as stated above, resulting in the table fitting on the page more accurately.

Sumhours_outputA2.pdf: PDF file saved from Jasper IReports

I could not upload the JRPRINT file - the upload dialog said it was an invalid file extension.

2

Hi

Thanks for your request. Could you please also attach a .jrprint file of this report? We will check the issue and provide you more information.
Best regards.

3

Hi Alexey
When I try to upload a JRPRINT file, I get the message:
Only files with the following extensions are allowed: zip,cab,jpg,gif,png,mpg,mpeg,avi,wmv,wma,mp3,ra,rar,rm,sql,txt,xls,doc,pdf,rdl,ppt,docx,xlsx,pptx,xlsm,tif,rtf,dot,xml,odt,odp. Please select a valid file.

I’ve attached the JRPRINT inside a ZIP file.
John

4

Hi,
Thank you for your inquiry.
.jrprint attachments are now allowed as well. I’m looking into your issue right at the moment.

5

As far as I remember, a while ago I rejected the idea of using cell paddings because they led to invalid table layout when being different throughout the table. However, I think it will be okay for the vast majority of JasperReports. I will try to replace paragraph spacing/indentation with cell paddings/alignment in the nearest 1-2 days. Then I will get back to you with news.
Thanks.

6

Hi Dmitry
How is progress with this going?
An chance of the changes being in today’s interim release?
It affects a number of reports I am developing.
Cheers,
John

7

I’m finishing it. Please expect an interim release shortly.

8

John,
While your suggestion is great and I have implemented it, there’s still a difficulty peculiar to flow layout in whole. I’ve noticed that in your document you set row height to auto, i.e. unchecked the row height checkbox. That made Word calculate the height based on cell contents, and that’s why the table in your document fits on the page nicely.
I can’t do the same, at least not in all cases. Imagine there’s a row containing empty cells only. It will simply collapse unless row height will be explicitly set. So I still have to calculate and set row height. What I have done is the following. I subtract the total of top and bottom cell paddings from the height because it seems like Word acually adds it to the designated height! That’s why table rows are longer than needed and that’s why the table often expands off the containing page.
This (setting a reduced height) still makes the table a bit longer than when the height is set to Auto. I’m pondering on what to do. Maybe introduce a boolean parameter controlling whether or not row height is set? You can disable it, but remember, row height will never exceed cell contents then, and empty rows will collapse.
If you have any ideas, please let me know.
Thanks.

9

Hi Dmitry,
Sorry I missed this until today.

> Imagine there’s a row containing empty cells only.
> It will simply collapse unless row height will be explicitly set.

This is the state a row is in when you create a new table in Word.
In an empty table, I can set the Table / Properties / Row / Height to X and the row stretches ok (see attachment: Empty table with row height set.doc)
Can you generate this from Aspose.Words?

Email a phone number if you want to discuss this.

Cheers,
John

10

Hi John,
Not quite. The row doesn’t collapse because each cell contain empty paragraph (paragraph breaks) which you can notice if you enable formatting marks in Word. Within cells, they look like turtle-like signs. select all of them and decrease the font size - and you will see the row collapses.
Therefore, I should either set row height explicitly or fill the row with an appropriate number of paragraph breaks of appropriate size. The former approach seems neater, doesn’t it?
Another difficulty is that text element’s height may be much bigger than the height of the text itself. Again, I should then either simply set the height of the row to an appropriate value or fill the spacing before/after the text with empty paragraphs to maintain the height.
So, as you can see, it seems not worth dropping the idea of using the row height Word’s feature. However, if setting the height often makes your tables higher than needed, I could, for instance, provide a boolean parameter that controls whether the height is ever set. What you would say about that?
Thanks.