Hey Mike, any update on this feature (or a potential workaround), or on when this might be implemented?
I see that there have been comments related to this issue since at least 2009, and it really is important to us. We're using Prince to typeset academic articles, and the large whitespace before landscape pages looks quite unprofessional.
Happy to hear that "float-defer-page" worked, in combination with JS-based post-processing. The property is an experimental feature and we are soliciting feedback. It would be interesting to hear if, e.g., one new value could replace the scripting you had to do.
Sure. I can give a little more context on the issue I ran into in case it would be helpful.
My desired behavior: I wanted to be able to place a landscape table at any point within an article without interrupting the flow of the text.
For example, suppose that a landscape table (let's call it Table 1) is inserted immediately after a paragraph (Paragraph X) that, once laid out, appears at the top of page 2. Normally, since my landscape tables use a different named page, inserting the table will cause an immediate page break. Table 1 would (correctly) appear on page 3, but this would leave a lot of whitespace on page 2.
Ideally, I would want Table 1 to fall on page 3 without forcing a page break -- that is, I would want the text following the table to move up and fill the rest of page 2, avoiding any awkward whitespace.
Issues with "float-defer-page" by itself: Initially, I tried adding the "float-defer-page" attribute without changing the location of Table 1 in the HTML (so that it was still placed after Paragraph X). I found that it was helpful in that the page prior to Table 1 was now filled with text and not awkwardly cut off. However, in the end it did not really resolve my issue since
1. The page containing Paragraph X was still awkwardly cut off, since the new named page required by the landscape table still inserted a page break.
2. Table 1 now fell later in the article than I wanted. Ideally, I would want Table 1 to fall on the page immediately following its preceding text (Paragraph X).
My hacky workaround: Ultimately, I was able to get the behavior I wanted by instituting the following transformations to the HTML:
For each landscape table in the article (e.g., Table 1):
1. Find the element preceding the table (e.g., Paragraph X). Add a class to that element that will designate it as the predecessor of the corresponding table (e.g., a class of "pre-<id of landscape table>").
2. Move the table to the very beginning of the HTML. This will ensure that it will not result in an awkward page break in the middle of the text.
3. Make the table invisible ("display: none"). This will ensure that our page counts are accurate in the next step.
For each landscape table:
1. Find its preceding element, which should be labeled with the appropriate class.
2. Use Prince boxes to determine the page on which that preceding element ends (e.g., page 2).
3. Defer the table by that number of pages, so that it will end up on the following page (e.g., page 3).
4. Make the table visible by removing "display: none."
5. Run layout again and repeat this process for the next landscape table.
I agree that it should be possible to have the table appear after paragraph X in the markup. It seems as if Prince always introduces a page break when the table asks for a specific page, even if the table is top-floating. It seems more useful to not have that page break appear for page floats.
The workaround for not is to put the table at the beginning of the document.
The issue is, as you say, that named pages still introduce breaks even if deferred. We'd like to improve this but at the moment we are working on other things.
In the meantime an easier workaround may be possible. If you style an element as follows then it should be placed on the next page by itself (or on the current page if it is already at the top), without introducing unnecessary breaks:
You can use, e.g., @page :nth(3) to style the page as landscape, possibly after determining its page in a first pass. Since it takes the whole page I think you should be able to do this for all landscape tables at once.