Home » Archived » BIRT » Horizontal page breaks and consistent row height
| |
| Re: Horizontal page breaks and consistent row height [message #1008439 is a reply to message #1008336] |
Tue, 12 February 2013 13:50   |
 Tor-Einar Jarnbjo
Messages: 7
Registered: February 2013 |
Junior Member |
|
|
Yes, using a fixed row height works, but since the amount of content in each cell is rather unpredictable, it is not really an option for me to calculate the row height manually.
I've added a minimal example showing the behaviour with the designer project, XML data source, designer preview (.png) and PDF output.
Except that the page breaks are ignored in the designer preview, the output there is as expected. The example is just a simple table with two columns and two rows. The cells R1/C1 and R2/C2 contain two lines of text, the cells R1/C2 and R2/C1 contain only one line of text.
In C1, I have the property "Page break, after" set to "always", so that C2 is forced onto the next page. In the PDF output, the height of the cells R1/C1 and R1/C2 should IMHO be the same and provide for the two lines of text in R1/C1. The cell height of R1/C2 does however only provide for one line of text, causing the rows R1 and R2 to be misaligned, if the pages are placed next to each other.
|
|
| | | |
| Re: Horizontal page breaks and consistent row height [message #1008556 is a reply to message #1008541] |
Wed, 13 February 2013 00:42 |
Tor-Einar Jarnbjo
Messages: 7
Registered: February 2013 |
Junior Member |
|
|
I am still not sure if my problem is clear. I do not want to use the maximum cell height for all data, but for all cells in the same row, just as it is actually done if no horizontal page break is used within the table.
If I use Excel-naming for the cells in my drawing (columns A-D and rows 1-2), the cell A1 contains three lines of text, B1 has two lines of text and C1/D1 both have one line of text. In the first row, the cell with the maximum height is A1 (three text lines). If all columns are output on the same page, the height of A1 is also used for the cells B1, C1 and D1 (all cells in the first row). If I have a page break between the columns B and C, the height of A1 and B1 is obviously calculated as max(height(A1), height(B1)), while the height of the cells C1 and D1 is calculated as max(height(C1), height(D1)).
Is the layout engine really working as expected here, when it recalculates the row height separately for each page? If the layout engine is consequent, turning the issue 90° would mean that column widths should be recalculated after a vertical page break as well, but they are not. If one table spans multiple pages vertically, the column widths are kept the same on each page.
|
|
|
| Re: Horizontal page breaks and consistent row height [message #1008773 is a reply to message #1008556] |
Wed, 13 February 2013 20:35 |
|
I understand what you are saying. I do not think the logic is in the code to handle rows like columns though. The main reason for this may be to conserve on the amount of white space. This about a table that has 10 rows. 9 of the rows are one line. The 6 row contains 8 lines of text. If each row was sized based on the 8 lines of text that would be a lot of white space. I still think this would make a great option for horizontal page breaks. From a stand point of overcoming the issue now, you could possibly script the height. For example, add a computed column to the data set that calculates the number of line feeds for a data item. Then add a max aggregation computed column to the data set to get the maximum for a row and then in the onCreate script set the row height based on the maximum value. See attached modified example.
Jason
BIRT-Exchange
|
|
|
| Re: Horizontal page breaks and consistent row height [message #1009077 is a reply to message #1008773] |
Thu, 14 February 2013 11:41 |
Tor-Einar Jarnbjo
Messages: 7
Registered: February 2013 |
Junior Member |
|
|
Both your responses and also the scriptheight.rptdesign example are not solutions to my problem, so I am actually pretty sure that we don't understand each other 
You seem to believe that I am looking for a way to get all table rows to be set to the same height, and you are probably right that I in that case would waste a lot of whitespace. That is not what I want and as you can see in my drawing, even in my expected layout, the rows are of different height. The first row has a height to provide for three lines of text, while the second row has a height to provide for four lines of text.
If we look at my example again (this time with named cells):
Each cell has the following number of text lines:
A1: 3
B1: 2
C1: 1
D1: 1
A2: 1
B2: 4
C2: 1
D2: 2
Now, to keep the rows aligned across all pages, the row heights must be calculated as follows:
Row1.height = max(A1.height, B1.height, C1.height, D1.height)
Row2.height = max(A2.height, B2.height, C2.height, D2.height)
While BIRT currently seem to do something like:
Page1.Row1.height = max(A1.height, B1.height)
Page2.Row1.height = max(C1.height, D1.height)
Page1.Row2.height = max(A2.height, B2.height)
Page2.Row2.height = max(C2.height, D2.height)
Note again: The problem exists only if a table is split horizontally across several pages. As long as all columns are on one page, everything works as expected.
Now, even if your scriptheight.rptdesign is a step in the right direction, it does not solve my problem and I don't find any obvious way using the scripting API to do so. One major problem is that you are simply counting the line feeds directly in the text from the data source. This will not work for longer lines, where BIRT automatically uses word wrapping to split the longer "physical" text line over multiple "layout" lines.
If there was a method in the scripting API to access the calculated height of each cell within a row, I could always work with that, but if I understand it correctly, the "this" reference in the DetailRow.onCreate handler is of type IRowInstance and from there, I only have access to the cell content and not the actual Cell instances, on which I could query the height?
Attachment: Scan002.png
(Size: 23.58KB, Downloaded 2694 times)
|
|
| | |
Goto Forum:
Current Time: Thu Apr 18 16:42:24 GMT 2024
Powered by FUDForum. Page generated in 0.07019 seconds |
] 
Search
Help
Register
Login
Home
