Welcome Guest Search | Active Topics | Sign In | Register

EO.PDF: Spurious page break at begin of <table> Options
Stefan Szomraky
Posted: Friday, October 2, 2015 8:02:48 AM
Rank: Newbie
Groups: Member

Joined: 10/2/2015
Posts: 2
We let users edit HTML with CKEditor and even allow WinWord copy&paste. So far everything works fine, CKEditor also does an amazing job in clearing up the pasted HTML.

But recently we noticed that EO.PDF inserts extra page breaks at the begin (i guess) of <table> elements. If I dump the HTML to a new Chrome browser window and use Chrome's "Print to PDF" feature, there is no page break visible. But weirdly enough EO.PDF's layout/rendering engine thinks it has to insert one.

Any idea what the cause is? I have also prepared an example project.
eo_support
Posted: Friday, October 2, 2015 9:54:08 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

You can send the html to us in zip format. See here for our email address:

http://www.essentialobjects.com/forum/test_project.aspx

Once we receive that we will look into it and see why the converter inserts the extra page break.

Thanks!
eo_support
Posted: Monday, October 5, 2015 9:03:15 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

We have looked into your test HTML. The root of the problem is you have this CSS rule in your CSS file:

Code: CSS
.lsr-document-content td,
.lsr-document-content tbody
{
    page-break-inside:avoid;
}


A page-break-inside:avoid on an element can cause extra page-breaks before that element if the element is bigger than the available space on the current page. When that happens, the converter will try to push the whole element into the next page in the hope that the next page would fit better (since it's a blank page so it could have more space). That would introduce a page break before this element and sometimes that's not desired.

Thanks!
Stefan Szomraky
Posted: Saturday, October 10, 2015 7:58:12 AM
Rank: Newbie
Groups: Member

Joined: 10/2/2015
Posts: 2
eo_support wrote:

A page-break-inside:avoid on an element can cause extra page-breaks before that element if the element is bigger than the available space on the current page. When that happens, the converter will try to push the whole element into the next page in the hope that the next page would fit better (since it's a blank page so it could have more space). That would introduce a page break before this element and sometimes that's not desired.


This fixes *this* problem, but sounds like a bug in the PDF renderer. The table won't break "less" on the next page, it is still bound to break. We found that this is a problem with many of our tables, the renderer starts with an empty page, pushes the element to the next empty page, and has to break the table there anyway.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.