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

Fix: page breaking on rows with rowspan. #2090

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Ujifman
Copy link

@Ujifman Ujifman commented Feb 17, 2020

  1. I added restriction to break before row, if page_break_before: avoid specified for <tr>.
  2. I added logic to define if current row has spanned from previous rows cells, so one restricts page breaking on rows connected with rowspan. Rowspanned TD element lost on page break #1388

- Don't break spanned rows/
- Don't break before row if page_break_before: avoid specified for <tr.>
@simonberger
Copy link
Member

simonberger commented Feb 18, 2020

@Ujifman I tested this and got the following pdf from #1388
dompdf_2090.pdf
In comparsion the pdf from dompdf current develop branch.
dompdf_dev.pdf

The header is missed on the follwong pages. I guess this is known/intended to be able to render it. But it breaks later when having one more row on pdf page 4.

@simonberger
Copy link
Member

@Ujifman To precise my testing and review of the code. Am I correct that your change delays the point a table with a spanned row breaks or should it completely fix the behavior?

@bsweeney
Copy link
Member

I don't know that this change is sufficient enough for the designated issue. It does make an attempt to keep rows with a spanning cell together, but Dompdf will still split a rowspanned cell across pages when the row it's on has already been paged. And since the real issue is that the row-spanned cell is lost from the table layout after the page break this doesn't really provide much relief.

Let us know if you feel we're missing something.

@Ujifman
Copy link
Author

Ujifman commented Feb 24, 2020

@bsweeney, sorry I wasn't clear enough. I didn't solve the problem fully. In my case I have small rowspans in pdf, i.e. rowspan is never greater than page length, so I check if page break came to spanned row, and go up to the span beggining to make a split. So as @simonberger saw in test, if rowspan is bigger then page, cells are lost. The only general solution is to copy spanned cell on every page break. So my solution is not full, but I think, it will be useful for those projects, who has spanned cells less then page length.

@Ujifman
Copy link
Author

Ujifman commented Feb 24, 2020

I wasn't clear enough. I didn't solve the problem fully. In my case I have small rowspans in pdf, i.e. rowspan is never greater than page length, so I check if page break came to spanned row, and go up to the span beggining to make a split. So as @simonberger showed in test, if rowspan is bigger then page cells are still lost. The only general solution is to copy spanned cell on every page break. So my solution is not full, but I think, it will be useful for those projects, who has spanned cells less then page length.

@bsweeney
Copy link
Member

Thanks for the clarification.

@simonberger
Copy link
Member

I would prefer to fix the actual bug. There shouldn't be the need to avoid breaks on rowspans aside of the current obvious problem.
But I agree to your argument that this change can work around the issue in at least a lot of cases and vote to merge it if we won't fix it soon.
I yet failed to find the missing information in the splitted table causing the overwrite of the spanned column.

@sektonic
Copy link

sektonic commented May 1, 2020

  1. I added restriction to break before row, if page_break_before: avoid specified for <tr>.
  2. I added logic to define if current row has spanned from previous rows cells, so one restricts page breaking on rows connected with rowspan. Rowspanned TD element lost on page break #1388

Thank you sir

@bsweeney
Copy link
Member

Let's push to the next release so we can better evaluate what to do with this. I don't want to implement something that we'll have to remember to roll back later even if it provides temporary relief.

@bsweeney bsweeney added this to the dompdf-next milestone Jun 14, 2020
@fillobotto
Copy link

Do you have any update about this problem?

@Mellthas
Copy link
Member

Mellthas commented Aug 2, 2021

Haven't looked into the second part, but the first change about page-break-before: avoid support for table rows would be nice to have independently of how the discussion is resolved. Can you put up a separate PR for just that change, @Ujifman, so it can be merged?

@bsweeney bsweeney modified the milestones: dompdf-next, 1.1.1 Sep 18, 2021
@bsweeney bsweeney changed the base branch from develop to master November 8, 2021 19:24
@bsweeney bsweeney modified the milestones: 2.0.1, 2.0.2 Aug 25, 2022
@bsweeney bsweeney modified the milestones: 2.0.2, 2.0.3 Jan 29, 2023
@bsweeney bsweeney modified the milestones: 2.0.4, 2.0.5 Jun 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants