Add visibility:-fs-table-paginate-repeated-visible for paginated tables.#32
Conversation
This allows to render some elements on the continuation of a repeated table header on a new page. E.g. a span containing the word "continued". For this to work the table must have -fs-table-paginate: paginate; set. Using visibility the element is always correctly layouted, but only painted after the table is broken into a new page.
|
I'm curious why the decision to implement this on the
and here's how the table header looks on subsequent pages: To me, a more standard use case would be |
|
This is an implementation limitation. The repeated-header row elements are only repositioned "as-is" and repainted on new pages. No kind of layout takes place on page breaks. So the only thing you can do is to paint or not paint something. Which this visibility style controls. Sorry, you need to move the [Continued] after the text. Everything else wont work. It might be possible to perform a layout of the table header row on every page break, but this will likely be very complex to implement. But feel free to try. |
|
Fair enough. I realized that placing it after would work well enough, and added some documentation for this in the Wiki. https://github.com/danfickle/openhtmltopdf/wiki/Page-features |
This allows to render some elements on the continuation of a repeated
table header on a new page. E.g. a span containing the word "continued".
For this to work the table must have -fs-table-paginate: paginate; set.
Using visibility the element is always correctly layouted, but only
painted after the table is broken into a new page.
@danfickle As with #31 feel free to suggest a better property name.
A customer of mine wants to have "(Continued)" in the table header if the table is broken across pages. This implements it.
I will update the testcase in #31 to use this feature if #31 is merged.
While implementing this I found out, that the table header elements are special handled in the BoxCollector. There is some "magic" which makes them repeat. So #19 might be just some wrong calculation in TableBox.updateHeaderFooterPosition(). I'll likely look into this in coming the next weeks.