Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support *-break-*: avoid in columns #489

Closed
rewrking opened this issue Jul 26, 2017 · 2 comments
Closed

Support *-break-*: avoid in columns #489

rewrking opened this issue Jul 26, 2017 · 2 comments
Labels
feature New feature that should be supported
Milestone

Comments

@rewrking
Copy link

This could be the same issue as #255, but it might not be, and figure a new issue would get more visibility anyway.

I'm having a problem with a client project I am using weasyprint for - dealing with multiple pages with dynamic content that generate optional pdfs users can download (typically arranged as header, body text & image). If I have several block elements with "page-break-inside: avoid" arranged inside of a parent element with "columns: 2" and one of the elements is positioned in such a way that its contents extends beyond the bottom of the page, the entire parent element (and the rest of the content contained within it) doesn't render, so you basically end up with huge gaps of white space where content should be. This is a big problem as the "columns: 2" method is the best solution for multi-column print layouts. Would be nice if this could be addressed. #255 mentioned an infinite loop and not producing a result, however this does actually generate the PDF, just with content missing.

Current workaround is to not use "page-break-inside: avoid" at all, which makes content broken up in uneven places that don't make sense in the print world. For example: a header appearing in the bottom-left column, and its body text & image appearing in the top-right column.

A solution for this problem would be to only break content across columns/pages in those cases where the content is too large otherwise - if its in column 1, and the content is greater than the full length of the column, break it up into column 2. If it's in column 2, and the content is greater than the full length of the column, break it up into column 1 on the next page. Essentially enforcing "avoid" first, and then breaking as a fall back.

@liZe liZe changed the title columns: 2 & page-break-inside: avoid issue Support *-break-*: avoid in columns Aug 18, 2017
@liZe liZe added the feature New feature that should be supported label Aug 18, 2017
@liZe
Copy link
Member

liZe commented Aug 18, 2017

This problem is different from #255 / #273. It's actually harder to fix.

Supporting *-break-*: avoid in columns is really, really, really hard. It's so hard that Microsoft browsers (!) are the only ones trying to follow these rules, Chrome, Firefox and Safari ignore them (see CanIUse). Some people in the CSS working group even told me that breaking blocks and getting balanced columns is a probem researchers work on.

We could just ignore these rules for now and get what other browsers do.

A solution for this problem would be to only break content across columns/pages in those cases where the content is too large otherwise - if its in column 1, and the content is greater than the full length of the column, break it up into column 2. If it's in column 2, and the content is greater than the full length of the column, break it up into column 1 on the next page. Essentially enforcing "avoid" first, and then breaking as a fall back.

Well, it would be simple if the content didn't have to be split equally between columns. Your example assumes that you know the height of the column during the layout of the content, but the truth is the other way: you have to do the layout of the content to get the column height. And if you're in a floating block, you don't even know the width of the columns container 😄.

The current balance algorithm is really bad, but I'm not currently interested in working more on this. The real solution would be to implement Fragmentation and Regions. It's a long journey, but it will be much better than hacking random algorithms like I did.

@liZe
Copy link
Member

liZe commented Apr 5, 2022

Fixed by #1619.

@liZe liZe closed this as completed Apr 5, 2022
@liZe liZe added this to the 55.0 milestone Apr 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature that should be supported
Projects
None yet
Development

No branches or pull requests

2 participants