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

Single widow line causes empty first page #1620

Closed
agoradesign opened this issue Dec 13, 2017 · 6 comments
Closed

Single widow line causes empty first page #1620

agoradesign opened this issue Dec 13, 2017 · 6 comments

Comments

@agoradesign
Copy link

agoradesign commented Dec 13, 2017

I have a problem, which may be related to #1617 and #1356, but is different in my opinion (although there's maybe a good chance that the same fix may help all different issues here):

A customer yesterday reported a generated PDF file having an empty first page. The second page is correctly rendered like you would expect the first page normally. And there's a third page, having single widow line.

I have managed to reproduce this problem locally as well with the online debugging tool http://eclecticgeek.com/dompdf/debug.php

I have experimented a bit by focusing on that widow line. There were 4 text lines at the end of the document, all separated by a <br> element, but not included in a parent paragraph element, only being inside a parent quite global div.

I could prove the correlation to the widow line by just eliminating the last line break, so that the "real" content can fit into one page --> the result was a correct PDF only having one page.

I have finally solved it for myself by using a parent <p> element wrapping these 4 lines, as they belong together anyway. After that change, the whole paragraph is rendered on the next page, which suits better anyway + the empty first page is also gone, which is the most important thing.

But nevertheless there must be something wrong calculated, as the empty first page should never happen. I can provide HTML triggering that problem. However I do not want to post the files publically (although already having changed the real address data inside, but there's still some real data inside). If you're interested in, just tell me, I can send it to you

@antoiba86
Copy link

antoiba86 commented Jan 28, 2020

Hello there,
I had this problem sometimes and randomly so it was very difficult to fix.
In local, the problem sometimes was fixed and sometimes ocurred.
In development it was the same. Sometimes I had the problem in local but not in development.

But today I integrated a functionality, in development and local worked perfectly but when I pushed it to production. The horror, sometimes a table was on the second page and the first page was empty.
If I added a <br> before the table, the problem was solved but I didn't like the style, so I started looking for the error and your issue opened saved my day.

I change an option in PHPstorm to remove widow lines and I started to delete and edit where the table was. Furthermore, encapsulate the table with a div tag.

And now, it was solved. I need to do more trying but it is a beginning. Thank you so much.

By the way, I leave the documentation to make that all widow lines disappear when PHPStorm save a file.
Configure editor to remove whitespaces in blank lines

@bsweeney
Copy link
Member

bsweeney commented Jan 31, 2020

@agoradesign this does seem to be a slightly different issue. I know it's been a while (sorry, I must've missed this issue), but was the problematic text a direct descendant of the BODY element? I'm wondering if maybe the logic to split an element at a page break doesn't take this into account and is splitting the page, then paging again because the end of the page has been reached.

@agoradesign
Copy link
Author

agoradesign commented Feb 3, 2020

wow, really long time ago :D but I still know that it was definitely not a direct descendant of the body element. There was at least one div wrapping the content

Right now, the template is structured as follows (and I'm pretty sure, it was exactly like that two years ago):

  • direct children of the body are 2 div elements, where the first is the fixed positioned footer of the document
  • the second div is the wrapper element for the content (.page). To be precise: the content is double wrapped, so there's another div wrapping the entity that is rendered there.. and then comes the content, which is differently structured. But the text causing the problems was a direct descendent of that inner div.. so what we can say, is that the parent element of the text was large than one page

body
..div.footer
....div.page
......div.order-step-entity
........content

@bsweeney
Copy link
Member

bsweeney commented Feb 3, 2020

Thanks for the follow up. Are you still encountering the issue and, if so, can you provide actual sample HTML+CSS?

@agoradesign
Copy link
Author

sorry for the late answer. well, the problem occurred on a website, we have implemented for a customer. on that site, there's an internal area for their retailers. There they can use some kind of mini ERP system, where they have the possibility to create offers, orders, invoices,... So, there are in fact many users. So we will only notice this issue, if someone complains about that. idk if some may silently live with this or other problems... as already some time has passed since the issue was reported, I can't exactly remember, how we solved it actually. I guess, it was some kind of workaround, that at least reduces that chance that this issue happens. don't know, if has really fixed it

@bsweeney
Copy link
Member

More than likely one of the page-break logic updates for the next release will fix this. If you come up a sample that fails with 1.1.0 post back and we'll look into it more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants