One approach to handle printing a highly dynamic forms with many tables is to take a very paper like approach to form design and use over-spill pages.
In paper forms today most forms that need to handle an unlimited amount of rows in a given table, have a section where the form shows a static number of rows. Say 5 - then it has a note at the bottom of the table, stating 'if you need to provide more rows, use this other form page (the over-spill page) - where this over-spill page simply contains a much larger number of rows for that table- and that's it. So lets say the over-spill page has 50 rows available. If they need to provide more rows, then additional over-spill pages are used, etc.
This same technique could be used to greatly simplify the logic required in an IBM Form to handle the same situation. so instead of attempting to calculate where we should split a page at runtime due to the highly dynamic nature of IBM Forms - we have well known split locations built in. So even when there are many tables, even on the same page, you use the same technique: You don't allow any content in the form to grow larger than the size of the printed page.
At run time we can add navigation buttons so that the user can easily navigate from the start of a given table to its remaining over-spill pages, and back.
Having extra over-spill pages in a form should not be a concern from a performance standpoint, as ODPL should be used, and they'd only impact the form if and when they're needed.
The over-spill concept could also be used in a print-only form - where the user at runtime would see a normal highly dynamic form, but the print only pages (or form) could leverage the over-spill technique.
An example of the normal dynamic form with 3 tables (relatively positioned below each other) has been attached to this article: before.xfdl.
The over-spill approach is then shown in the other attached form: overspill.xfdl. Where the overspill.xfdl form is able to collect the same data, but also be able to print it with full control over pagination.
A few things to note about the overspill form:
The content on the first page is never allowed to grow beyond the size of a printed page. So each table is limited to 10 rows maximum, and if additional rows are needed, then the overspill pages are used.
The "Add New Row" buttons are smart enough to know when to simply add a new row or navigate the user to the overspill page. There's a few binds added to the form to control these buttons and their relevance (ie visibility).
The forms print settings are setup such that the overspill pages are only printed when they are needed.
<pageref compute="PAGE1.TABLE1ROWS.value <= '10' ? 'TABLE1_OVERSPILL' : ''"/>
<pageref compute="PAGE1.TABLE2ROWS.value <= '10' ? 'TABLE2_OVERSPILL' : ''"/>
<pageref compute="PAGE1.TABLE3ROWS.value <= '10' ? 'TABLE3_OVERSPILL' : ''"/>
Where the number of rows of each table are looked at, and only if they have less than or equal to 10 rows, do we omit the corresponding overspill page from the print output.
The attached overspill.xfdl sample form does still have the limitation of only supporting maximum of 60 rows in each table, but now that we've used this overspill approach adding the logic to add additional overspill pages should be relatively straightforward - or at least much easier than attempting to handle 3 dynamically growing tables, and trying to figure out how and when to move them around. The techniques discussed in the Printing_a_Page_Scrolling_Form_Sample
article could be used to create new overspill pages dynamically.