Fit page height with JasperReports detail band

A report contains a unique central "Detail1" band that must fit the whole page height--even when the datasource provides just one record--the footer must remain at the bottom of the A4-sized page:

 _______________
|    header     |
|               |
|    row1       |
|    row2       |
|               |
|               |
|               |
|               |
|               |
|   footer      |
|_______________|

YES!

 _______________
|    header     |
|               |
|    row1       |
|    row2       |
|   footer      |
|_______________|

NO!

I wonder whether this is related to the "stretching" options or to the background.

Solution

We also have this more general problem of vertically sizing some band or content relative to the page height. In your case it could be done, e.g. by either increasing the row2 "bottom margin" or the footer "top margin" (or introducing some "spacer element" inbetween):

variant A    variant B   variant C
___________  __________  __________
|  header |  | header |  | header |
|_________|  |________|  |________|
|  row1   |  | row1   |  | row1   |
|_________|  |________|  |________|
|  row2   |  | row2   |  | row2   |
|    .    |  |________|  |________|
|    .    |  |    .   |  | spacer |
|_________|  |    .   |  |________|
|  footer |  | footer |  | footer |
|_________|  |________|  |________|

The only way I currently can think of to solve this, is kind of a hack, if "you know enough about the size of the to-be-streched element siblings":

We want to set the spacer.height (or margin depending on the variant chosen) like this:

spacer.height = page.height - header.height - row1.height - row2.height - footer.height

Example A

Let's assume for simplicity of this example that

only row2.height is flexible (~ dynamic)
for simplicity let's say row2.height is made of numbers separated by linefeeds like this:
```
17
2
34
```

Using variant A we could manually test, after how many linefeeds/numbers the footer would be pushed on the next page, let's say 5.

So all we would have to do is to

either dynamically adjust the bottom margin of row2 to max( 0, 5 - row2LinefeedsCount * row2lineHeight ) (e.g. via Groovy or Java)
or if it is based on some SQL select, fill in some blank space lines like this:

    -- (Oracle SQL)
    select 
      ...,  

      dyn_row2_col
      -- add additional linefeeds if necessary (when < 5 lines)
      --   (counts by the content length after removing all digits)
      || lpad(
           '', 
           max( 0,  5 - length( regexp_replace( dyn_row2_col, '\d', '' ))),
           CHR(13) )
      as dyn_row2_col,

      ...
    from ...

Example B

Another example could be, that row2s height is dependent and linearly increased by the number of subrows of some query result (e.g. if it is a simple subreport with equally sized rows). Then we could maybe use variant C and fill the spacer (invisibly) with some dummy query based on the subrow query (and doing the calculation of the rest space similar to the above example).

search engine tags/phrases

fit band height to page size/height, band height 100% of page size, max-height, stretch vertically to 100% parent container height or page size

implementation/usage thoughts of Jasper Reports

I find it a pain to not be easily able to use flexible positioning/sizing expressions (e.g. to let the footer stick to the bottom, float elements horizontally (e.g. table columns) or spacer.height: 75%) with Jasper Reports in this modern flex layout HTML/responsive layout world. The absolut positioning philosophy should be enhanced here. Eclipse BIRT is much better at this, but has other disadvantages. Of course the implementation could be quite complex, more memory intense and slower, but I think the benefit in non-absolute positioning requirement scenarios would be great.

I wrote some general Scriptlet (I plan to provide in jasper-utils), which solves the floating of horizontal columns based on named component styles (similar to CSS classes) on related columns. It behaves very similar to HTML tables, using the available horizontal space based on column-specific percentage and "underflow-stretch-calc" expressions and the possiblity to show/hide columns (over all related bands).