I have a document with multiple pages. When there is more data to display that does not fit on the first page it should display a text “SEE NEXT PAGE” in the footer; for the last page this text is not visible.
This works fine when I create multiple master pages.
Since the height of the footer scales I have an issue where for example I have a document with 2 pages the height of the footer for the first page is higher than the height for the second page.
In my Post Pagination script I set the height for the header and footer section in the merge.section.margins section.
The post pagination script is only called once and not for each page, so the height for the last page becomes leading and thus the margin for the first page is not correct anymore.
I would like it to use the highest margin it can find for all the pages and use that in the Post Pagination script.
As a general script is called multiple times I figured I just create a few global variables, fill them with the height of the section by doing a query(…).height() and then for the second time it is called I compare what I already had and if it is bigger I just use that. Problem is that for the first page it returns 0 and only after the first run the global variables are filled in. So a compare becomes useless as even with this the 2nd page will always be leading.
Just wanted to place an update here regarding this item.
I have 2 different footers…one with a “Please see next page” text and one without.
As the heights for the top/bottom margins are calculated before the paginate call it can happen that initially the text would fit on the page due to the master page being used that does not have the “Please see next page” text. After the paginate the text is reformatted and the system sees that the text does not fit anymore on the page and thus 2 pages are created. The height was already calculated and thus it uses the wrong height.
If I want to keep using a dynamically scaling header/footer I need to calculate the height again after the first paginate and then call the paginate a second time.
For now this solution works and I do not see any other other way than setting the margins in the properties for the print context manually so that it will immediately go to a second page (which was suggested by support). It can then still be changed in my post pagination script.
Unfortunately this would required careful documentation as in 6 months or a year I have no idea anymore why this was enabled. So I opted for the first solution so I can at least comment it properly in the code with the reasoning behind it.
Why are you using a Post Pagination Script in the first place?
Why can’t you simply let the inner pagination system do its thing?
You could have 4 Masterpages:
Single, which doesn’t have the footer “SEE NEXT PAGE” First, which has the the footer “SEE NEXT PAGE” Middle, which has the the footer “SEE NEXT PAGE” Last, which doesn’t have the footer “SEE NEXT PAGE”
Might be that I am missing some specs but it seems pretty straigh forward.
I was not aware that this would work with a header/footer where the size is dynamic and can scale based on the amount of information in it, which is determined by certain conditions that can vary based on the input file.
I have to confess I never tried it BUT it is worth trying no?
Since all the condition will be evaluated in a Control Script, it would be executed before the rendering of the sections.
How would this work then?
Since the heights for the header/footer are dynamic the top/bottom margin needs to be set by the system at runtime and you cannot rely on the margins that are set on the Master Pages.
Margins are not applied unless the paginate is called. So this will require a Post Pagination script as paginate cannot be called from somewhere else.
Setting the margins cannot be done in a control script as query cannot be used to query the height of a certain block and then set the margins with that.
And merge.sections also does not exist in a control script so setting the margins is not possible there.
The internal rendering system will only work with fixed header/footer margins.
Running query in a standard script to find the height and setting the margins will be possible from a standard script but those heights are calculated before the paginate command so they are not correct before the pages are rendered completely.
As such another query command to calculate the height after the first paginate and then a second paginate is required to apply the correct margins.
I am not sure about your statement that margins can only be aplied via a Post-pagination script and not a Control Script…see margins.
I don’t pretend I do understand your whole setup, perhaps if you’d share your Template with some dummy data to reproduce the behavior, it would be easier to understand. If you do, make sure to anonymize the data.