-fs-table-paginate: paginate or running elements missing background-color on second page

[schmitch]

Hello, currently I used openhtmltopdf with a simple html

<table>
<thead>
<tr>
<td><div class="classWithBackgroundProperty"><table><tr class="green"><td>hello world</td></tr></table></div>
<tr>
</thead>
<tbody>
// Page Breaking Body
</tbody>
</table>

however on the second page the background is not colorized. But other css properties like font-size font-weight are correctly applied. it might be noted that I apply the css via:

.ba-head-title table tr.green td {
    background: #4ce10b;
}

The same applies to running elements.
Also when I use the above on the second page the margin between the header and the body diverge. So they are not equal

[schmitch]

Looks like this is happening when there is a:

table{
    -fs-table-paginate: paginate;
}

tr {
    page-break-inside: avoid;
}

besides that these two should not affect the inner table at all

[rototor]

@schmitch Do you have a small test HTML file to reproduce that problem?

Table pagination is tricky and buggy. For good and stable results you should try to avoid breaks in a tr at all costs. If you can estimate the size of the tr you should use the style -fs-page-break-min-height:??cm on the tr. This would force a pagebreak before the tr if not enough space is remaining on the page.

E.g.

<tr style="-fs-page-break-min-height:5cm">
...
</tr>

If you use some form of a template engine to generate the HTML for your report you could use it to calculate the needed height on the fly. -fs-page-break-min-height also works on tables, divs etc. In my reports I always use -fs-page-break-min-height on the tr's of multipage tables, as otherwise you will get broken pagebreaks in some special case - which only happen with live data from customers :)

Yes, that's a workaround. But getting the pagebreaks right in all different scenarios is very hard. You might notice that all browsers just cut the page in peaces without bothering about nice pagebreaks at all.