|
|
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.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi, You can send the html to us in zip format. See here for our email address: http://www.essentialobjects.com/forum/test_project.aspxOnce we receive that we will look into it and see why the converter inserts the extra page break. Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
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!
|
|
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.
|
|