Prevent mid-row split on page crossing

[BlueWlvrn]

Is there a method to prevent a row from being split when that row causes a page crossing? I know in my table none of my rows are very vertically large, so visually it would be best to avoid splitting in the middle of a row and just push the row to the next page.

Thanks

[PhilterPaper]

At the moment, no. However, it should be possible to request a list of row heights (ink => 0, returning @vsizes array) and make a decision on which rows to output on this page, and which to defer to the next page, by adjusting the available table height. See examples/vsizes.pl. Does that work for you?

[BlueWlvrn]

I think the challenge there is you only have two heights to pass in which doesn't help when a table spans more than 2 pages.
Is there anyway to render a text block but not commit it to a page? It seems that almost all of the PDF::Builder functions write to the page. If one could "propose" a text block and check for left overs, it would be easier to not commit any of that cells paragraphs.

[PhilterPaper]

Hmm, I guess it could have trouble over more than two pages. Let me think about allowing a list (array) of next_h sizes, which you could select to fit entire rows on a page, without splits. As far as your request for a tentative write, with back-out on its ending up split, maybe it could get the height each row (ink => 0) and and then output the row on this page only if there is room. I'm not enthusiastic about that, as it would take at least twice as long to run. Let me mull it over for a while...

[BlueWlvrn]

Yeah, it seems to my, new to this pdf stuff, view that an ability to render something and not attach to a page would help a lot here. That'd need to be something added to PDF::Builder I think.

[PhilterPaper]

There's some discussion of this in PhilterPaper/Perl-PDF-Builder/issues/95, but this appears to be a massive change to the architecture of PDF::Builder.

Also, since PDF::Table is supposed to also work with PDF::API2, it would require that API2 also be updated -- who knows if that would ever happen. I think it would be best to keep in purely in PDF::Table. If you don't mind eating the performance hit of test formatting each row, and then writing it out for real if the whole thing fits, that might be possible. The alternative is to permit a list of page heights (rather than a single value), after you've run with ink => 0 to find the needed heights for each row, throwing more of the burden on the application calling PDF::Table.