Hi Brian,
As you guessed it, I do have a reason for not breaking the table
element as the code source of the page used to generate the PDF is
also used to render a in a ligtbox where I need all the data to be in
the same table. I thought of breaking the table but then it would
require almost a full re-work on my lightbox which is already quite
complicated enough.
I'm sorry but I cannot provide a relevant document as this is sensible
information of my company. But basically what I'm doing is applying a
"border: 1px solid #ddd;" on td cells of the table, then I've inserted
a page-break div in the first cell of the row I what to move to the
next page. The page-break works fine but domPDF is messing up the
border of the previous row (on the previous page then) by drawing only
half of the bottom border.
I filled the enhancement request, good idea.
Cheers,
Nicolas.
On Jul 8, 3:52 am, BrianS <
eclecticg...@gmail.com> wrote:
> What about closing your table and starting a new one at the point where you
> want to break the page? I'm sure you have a reason for not doing it this
> way, but this would avoid your problem. If you provide a sample document we
> might be able to come up with a better solution.
>
> Also, in quick testing with Safari I don't get a page break by applying
> page-break-before to a TR element. According to the spec<
http://www.w3.org/TR/CSS2/page.html#page-break-props>
> :
>
> User Agents must apply these properties to block-level elements in the
> normal flow of the root element. User agents may also apply these properties
> to other elements, e.g., 'table-row' elements.
>
> I haven't worked on this feature, but more than likely support for the
> page-break property on non-block elements hasn't had much work since it's
> optional. Might be worth posting a feature request<
http://code.google.com/p/dompdf/issues/entry?template=Enhancement%20R...>to help it make it into the final release.