Forum How do I...?

Prevent pagebreak when text overflows?

zambadu
Hi,

I've seen it is not a really new problem here in the forum, but I couldn't find an answer which fits my need.

I have some HTML elements on one page which should be one page in the PDF too.
If the last elements on the webpage have overflow, prince makes a new blank site in PDF (if the overflow is hidden, anyway the overflow can seen on the additional page). That seems to be the estimated behavior right?

So is there a way to avoid this new empty page, when overflow should be hidden?

All elements have a fix height, mostly overflow:hidden. I have also tried to give @page a height and overflow:hidden. But it seems that prince add the full heigth (I think its called the InnerHeight), including the overflow, to the PDF.


Thanks in advance and kind regards

zambadu

Edited by zambadu

mikeday
Specifying "overflow: hidden" is not enough to prevent a page break, you need to specify a fixed height for the block as well.
zambadu
Hi Mike,

also with a fixed height, they will result in an empty additional page. Prince 9 is used.
mikeday
Can you attach a sample document here demonstrating the problem?
jorma
I'm having the same problem. I have attached the most basic sample I could come up with. And the test output that I get with prince 9.

I would expect the second div to be under the first one on the first page. But the text inside the fixed height div overflows behind the div and pushes the second div off the page. When selecting text on the page you can tell the text is there and selectable.
  1. index.html25.1 kB
    The HTML
  2. test2.pdf38.6 kB
    The output
zambadu
Thanks jorma, this is exact my problem, too.
mikeday
That is odd; it seems to be interacting strangely with the page-breaking in this situation. Thank you for the very clear test case, we will investigate this issue.
zambadu
Maybe it will help you: When the Container has position:absolute, the overflow will hide as expected, but if it has position:relative, the empty page appears.
mikeday
Right, it seems that Prince is not taking the overflowing content out of the normal flow, as you would expect it to do in this situation.
jorma
Glad we found the problem. I'll try absolute positioning as a work around.
wachunga
I'm also experiencing the described problem with additional page breaks. The overflowing content even pushes down subsequent divs that have position: absolute and are anchored relative to page bottom (left: 0, right: 0, bottom: 0).

Pulse Energy

wachunga
In my case also, setting .page to have position: absolute (instead of relative) avoids the extra pages.

Pulse Energy

adriencater
I'm having a similar problem, with an image.

I have an image container structure containing an image which is larger than the container (cropped in a frame). exampleish code:

<p>lorem ispum</p>
<div class="outerContainer">
	<img src="foo.jpg"/>
</div>
<p>lorem ispum</p>


.outerContainer{
	overflow: hidden;
	width: 80mm; 
	height: 80mm;
}
.outerContainer img {
	height: 158mm;
}


if the img has a height of over 158 mm (well, 158.20144mm to be very exact), the .outerContainer and the following paragraph break to a new page.

File is attached with a lot of other very complicated image layout trickery, but the problem is visible on the last page, a simple layout with two text blocks around an image.
  1. ImageCSS.pdf69.0 kB
    output with errant break
  2. ImageCSS2.pdf68.6 kB
    output without break height: 158.20143mm
  3. imageCSS.html8.4 kB
    img layout test, "problem" on line 159

Edited by adriencater

adriencater
I've cleaned up the test file, removing any extraneous material to keep the test clean. Structure is the same as in the previous post.

I've found that the page margins have an effect on the maximum height the image can set to before it breaks to the next page, as does the amount of text before the image. (the margins, of course, have an effect on the number of lines in the preceding text, so they might just be a proxy for the real determining value…)
  1. imageCSS-overflowTest.html1.2 kB
    clean test file
  2. imageCSS-overflowTest.pdf62.2 kB
    test PDF output

Edited by adriencater

mikeday
It's because if the image is any bigger, it won't fit on the page. Yes, it's relatively positioned, but that only moves it relative to where it would have been placed if packed normally, ie. on page 2.

You can see this by removing "overflow: hidden" and the "position: relative" and putting a border on the @page. As the image gets bigger, it will get pushed to the next page instead of overlapping the page border.

To fix this, you can make the image use absolute positioning, then it will be taken out of the normal flow and won't break pages. However, you will need to relatively position its container element to make sure it is positioned relative to the correct origin, if that makes sense.
adriencater
This seems a bit capricious, since the positioning conflict is invisible.

In the code example above, the .outerContainer has a specific height of 80x80 mm, and it's that 80mm box which is placed in the page flow, the visible box taking up space on the page.

The outerContainer has it's overflow:hidden; rendering content outside of its boundaries invisible, and, one would expect, having no effect* on the layout – no matter what the size or positioning of that hidden overflow.

(*well, unless you keep in mind the difference between visibility: hidden; and display: none;)

I've opened the two test PDFs from my poste above in a vector editor, and it's not obvious that the image is bumping against a margin, or that a margin bump is responsible, since the image is already positioned far out of at least one of the margins. (screenshots attached)

As per your suggestion, I've tried specifying the outerContainer to have a position: relative; and the .outerContainer img to have a position: absolute; – but the page still breaks if the image size goes over a certain threshold! (Example HTML attached)

I think it's basically the same situation/bug as described in the opening posts of this thread – "that Prince is not taking the overflowing content out of the normal flow, as you would expect it to do in this situation."
  1. ImageCSS2.pdf.png342.6 kB
    Image not really close to margin
  2. imageCSS-overflowTest-absolute-relative.html1.2 kB
    It still breaks the page at 189mm!
  3. imageCSS-overflowTest.pdf.png436.6 kB
    image already a bit out of R margin
mikeday
Yes, this is something we are going to have to address. Thank you for the detailed test documents, it helps!
mikeday
We have included a workaround for this issue in the latest build.
zambadu
Hi, sorry to invoke this old topic, but I have the same problem as I described initial (oh dear its almost 6 years).

I actually migrate to Version 13, and this comes up again.

I have attached the HTML with included CSS and the produced PDF. There is again an empty page between. I have tried to increase the page size by a lot to look if it is a problem with overflow, but the empty page still occurs. So maybe the problem is different. It only occurs on this one, other conversions don't have this problem, so it must have something to do with the structure or css or both.

Any ideas?
Thanks in advance.
  1. 20210129094034pvdoc6012dbc2d47bc52e253666ed.pdf4.6 MB
    pdf
  2. testEdition.htm20.6 kB
    HTML
markbrown
We'll investigate this issue. Thanks for letting us know (again)!

EDIT: The issue is actually with the <div class="breaker"></div> element, which gets its own page because it is not on a named page itself, whereas the surrounding elements have "page: page6". One way to fix this is to put the element on the same named page, as follows:
.breaker {
    page: page6;
}


I also found the above sample was overflowing each page due to the following height declaration:
.dpage_6 {
  ...
  height: 2550px !important;
  ...
}

If you're still getting empty pages you could also try deleting that line.

Mark

Edited by markbrown

zambadu
Hi Mark,

thank you so much for your investigation. It was the .breaker, didn't think of this part, as it has worked before we used the page: logic, but it is clear now.

Thanks again for figuring out!