Tables overflowing page limits

[RafaelLinux]

I'm not sure if is a previosly commented issue, but this is the case: Two distinct tables are overflowing page limits, one at bottom and the other one at right. In the screenshots, you can compare Firefox print preview output (left side) and weasyprint output (right side). I coded CSS to show on screen closer to print output, and on screen, the table overflowing at right is correctly displayed.

I'm using latest weasyprint and parameter "--presentational-hints"

This is the table overflowing at bottom:

This is the table overflowing at right:

weasyprint issues.zip

Any idea what's wrong?

Thank you

[liZe]

Hello!

This is the table overflowing at bottom:

That's because we can't break pages in a table line. See #36.

This is the table overflowing at right:

That's a different issue. I have to check what's happening.

[liZe]

I have to check what's happening.

There's a 'width="793"' attribute set to your table, looks like it's larger than the page.

So for me, there's nothing wrong in WeasyPrint (except for the first case corresponding to #36).

[liZe]

(By the way: the page style is much better like this 😉)

[RafaelLinux]

That's because we can't break pages in a table line. See #36.

So .... I'm in trouble. Despite page style "maybe" is better :P we have no control about the content of the table lines. Usually, tables have large cells that contains text, so we can't do nothing about it cause the format must be respected for legal reasons. That's a big inconvenient if we want to use Weasyprint ... I need to think if we can use a workaround cause we was betting for weasyprint as final solution to obtain PDFs :(

There's a 'width="793"' attribute set to your table, looks like it's larger than the page.

Unfortunately, that's a table property assigned by editors, but it's override as you can see, by CSS. As you can see on screen and when previewing the print, the tables are adjusted to they content, ignoring the width.

Thank you for your clarification

[liZe]

Unfortunately, that's a table property assigned by editors, but it's override as you can see, by CSS.

Oh, I see. None of the values you set in CSS are supported by WeasyPrint (unset and fit-content). Adding width: auto before width: unset will work.

[RafaelLinux]

I tried adding adding width: auto before width: unset has you suggested. It solves the right-side overflowing, but have ugly collateral effects over all the other tables in document. This is the comparison screenshot. At the left side is with the original CSS. At the right, with you suggestion:

But here, a piece of collateral effects on the other tables:

And while inspecting the effects on all the document, I discover accidentally something very worrying, not related with the CSS, but with weasyprint. Take a look at this screenshot:

As you can observe, a little table is dissapeared just when it's between pages. The html code for this table is simply:
<table cellspacing="0" cellpadding="0" border="1"><thead><tr><th id="th069E20400000" valign="top">Anexo IV<br>Contrato menor</th></tr></thead></table>
I'm afraid it's consequence of bug #36 , but not sure.

That bug is a stone in the road in our way to use weasyprint :( , cause we can not lost any word in our PDFs.

Thank you for the suggestion about the CSS.

[liladude]

Hello, I am here to report a similar related problem. I have tables with really long text on them, which is why I have put "td {page-break-inside: auto;}" in my css (even if this should be the standard). Unfortunately the table overflow my bottom margin... and it only happens with weasyprint (so far)!

[liZe]

As you can observe, a little table is dissapeared just when it's between pages.

I'd really like to have a short HTML sample showing this problem, because I can't reproduce.

[liZe]

Hello, I am here to report a similar related problem. I have tables with really long text on them, which is why I have put "td {page-break-inside: auto;}" in my css (even if this should be the standard). Unfortunately the table overflow my bottom margin... and it only happens with weasyprint (so far)!

This is what's reported by bug #36.

[liZe]

That bug is a stone in the road in our way to use weasyprint :( , cause we can not lost any word in our PDFs.

We've greatly improved the way tables are rendered between pages in #941. #36 is not fixed yet, but we can now use break-* rules for tbody and tr, and we don't lose tables anymore.

I think that I can close this issue, as:

• we don't break tds, but that's what Allow page breaks in floats, absolute blocks, table-cells #36 tracks,
• we're able to correctly break between trs and tbodys, even respecting break-* rules,
• we don't "forget" lines anymore.

Feel free to reopen if there's anything I didn't think of!