Table with "float:right" duplicates at the start of a page #1792
Comments
Task #073209
Task #073209
|
I have been exploring the cause of this issue. I haven't yet worked out what the best solution to it is, but I think I'm on the right track. Apologies for the long post, as there's a few different aspects to this issue. As observed in the original ticket, it seems that this issue appeared in v54. As such, I've been comparing the differences to how v53.4 handles it to v54. A few things that I found interesting when playing around while rendering in v54, with HTML based off the HTML provided in the original description. Here is the rendering of a 12 row table without float. You will see here that the table goes over multiple pages, with rows numbered 8 to 12 (inclusive) going across to the new page. Here's the same HTML rendered, but with a What I found very interesting was that in all my testing, the part that's repeated is the section that would be rendered on the second page if the table wasn't a float. In this example, rows numbered 8 to 12. So that got me thinking, what would happen if we had a table that spanned over 2 page breaks, instead of just 1 page break. I made a table with 80 rows. Here's is the rendering of an 80 row table without float. Here's the same HTML rendered, but with a As I had thought might happen, mayhem ensues. All of the table is rendered on one page (page 2). There is no page 3. So the issue has to do with handling continuing the table when it goes over multiple pages, or where Weasyprint thinks it goes over multiple pages. So with the 12 row example, without the float, the table is spread across 2 pages. Whilst the float causes the beginning of the table to be pushed to the new page, there seems to be a bug where Weasyprint thinks that it goes over multiple pages. I've pinpointed the handling of this to be this logic that appears to have been added in in v54: If for example, you were to take the if statement that checks if a box is a float, and just not do anything, you don't get the original bug. In my testing, I just did: and the original bug no longer happens. However, this would likely mean that there's no multi-page support for tables that are floated. Which brings me back to v53.4, and how it handles multi page support for tables. The long story short is, that it doesn't. Here's a screenshot of the 80 row floating table from v53.4:
There is no page after this. The table just goes off the page. So it seems that this issue was introduced when solving #36. Which is why, whilst it's easy to fix this issue by not supporting page breaks, I'm not really sure what the ultimate fix is. We can't just revert back to disallowing page breaks in floats, as that is a valid use case, and I assume that there are situations where this code is behaving as expected. |
|
A bit of further investigation to find out how it gets into the It looks to be this code I'm not suggesting this as the fix, as I am not experienced enough in the WeasyPrint codebase to fully understand why |
(Tested in 54.3 and 57.2)
If we create a document where we have a page jump and a table with "float:right" attribute at the start of the page, part of this table duplicates (in this case, the table with the red border):
If we delete the "float:right" form the table, the table works correctly:
Here is the html code i use for this example:
The text was updated successfully, but these errors were encountered: