Nested Tables and Height

Hi all!

I am creating a report which basicaly consists of a table with a nested table in one of its cells. The point is, when the cell (i.e: the row) containing the nested table is higher than the nested table itself, there's empty space at the bottom of the cell. (see attached file)
I wondered if there was a way for the table to fill the cell entirely. (i tried to set the table "height" property to 100%, but it won't do anything).

I'm using Birt version 2.2.2, eclipse 3.2, and the cell containing the nested table has a colspan of 7 (I don't think there's any relation, but you never know...). The report output is only pdf.

Thanks.

Find more posts tagged with

Comments

mwilliams

Hi thias,

I think you forgot to attach the file you mentioned. If you could recreate your issue with the sample database, that would make it easier for me to see your issue. Thanks.

thias

Ok, there comes the missing file (i think it was too big the first time), and the .rptdesign. I'd rather not use the sample database, though, because this isn't my data inside.

Thank you.
Mathias

mwilliams

Mathias,

The reason for the sample database version would be so that I could actually run the report design so I could test. Then, if I found something with it, the same concept should then work on your design. I'll take a look at your design though to see if I can just see something you could do.

mwilliams

Mathias,

What is the reason for using the nested table and not just putting the data elements in the cell?

thias

Hi Michael, thank you for your quick answers.

I unfortunately can't provide you a sample data, but my issue is quite easy to get with the zipped image: i just need the nested table's height to fit(match...?)- pardon my English, it's been a long time...- with the containing cell's height.
When the table is higher than the cell would have been without it, it's ok because the row's height grows, but when the table is smaller, i would like it to grow and fill the containing cell.
In the image I joined, that means there would not be light blue (the containing cell's background color) anymore.

mwilliams

Mathias,

I understand the issue clearly. A report design showing the same issue with the sample database would just allow me to test ways to get rid of the extra space. Can you explain why you use an embedded table in the report rather than just putting the data elements directly into the outer table? From the image, it looks like those tables only contain 1 row each.

thias

OK, I just put my report's first page to show clear spaces, but i realize it would have been smarter to show rows with several line in the embedded table.
I joined a database sample which i created myself with fake data (i don't know why i didn't think of that sooner), that should do the trick. You'll probably have to adjust certain things though, like changing the MARCHE table name into VIEW_MARCHE and maybe column aliases as well. Don't hesitate to ask.

thias

Still no idea?

mwilliams

Mathias,<br />
<br />
Sorry for the delay. Time has been an issue as of late

. So, rather than setting up your example, I just quickly created a similar situation with a few computed columns. There doesn't seem to be a way to stretch the table height with the 100% value. It didn't work in the latest version, 2.3.2, either. Using a specified height works in HTML, but not in pdf. This probably wouldn't work for you anyways though because your height depends on other columns. Please search the bugs at <a class='bbc_url' href='http://www.eclipse.org/birt/phoenix/reportabug.php'>BIRT: Reporting Bugs and Requesting Enhancements</a> and file a bug on this if there isn't already one and see what they say. Be sure to include a good description and screenshots. Possibly even your report design with instructions on how to set it up to run. Thanks.

thias

Michael,

Thank you very much for the time spent on my issue, I'll report it as you told me. Thanks again.

Mathias

mwilliams

Mathias,

No problem. If you could post any bug info you find or report, in here, for future reference, that'd be great. Thanks.