Home » Archived » BIRT » Horizontal page breaks and consistent row height
| Horizontal page breaks and consistent row height [message #1008178] |
Mon, 11 February 2013 04:43  |
Eclipse User |
|
|
|
I've been trying to use the horizontal page-break feature, so that wide tables are split between columns across multiple pages.
It sort of works, but not exactly as I expected. Just as column widths are kept consistent across multiple pages when using vertical page breaks, I would expect that the row heights are kept consistent across all pages when using horizontal page breaks. I am not sure if I simply have to adjust a table property somewhere, but with the default values, BIRT 4.2.1 recalculates the required row height for each page separately, so that table rows are likely to be misaligned, when the pages are placed next to each other.
Anybody with an idea how to get horizontal page breaks and keep the row height across all pages? Using a fixed row height is not an option.
|
|
| |
| Re: Horizontal page breaks and consistent row height [message #1008439 is a reply to message #1008336] |
Tue, 12 February 2013 08:50  |
| Eclipse User |
|
|
|
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] |
Tue, 12 February 2013 19:42 |
| Eclipse User |
|
|
|
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 #1009077 is a reply to message #1008773] |
Thu, 14 February 2013 06:41 |
| Eclipse User |
|
|
|
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 2937 times)
|
|
| | |
Goto Forum:
Current Time: Thu Mar 27 02:24:38 EDT 2025
Powered by FUDForum. Page generated in 0.04896 seconds |
Home
