CSS not respected: page-break-after: always; Phantomjs 2.0

[shaidams64]

Hi, I am using Phantomjs 2.0 and still have problems with page breaks, I followed the suggestions in #10638 but none of them seems to be working for me. Also, do you still need to set page.paperSize in phantomjs script even when you are setting page breaks in the css stylesheets? I really appreciate it if somebody could help me. I am trying to generate pdf reports and this is the last bit of the puzzle! Thanks in advance.

[skohli0302]

+1

[hrvolapeter]

+1, I'm for now using hack in javascipt to fit divs to page height

[dtru]

+1

[yayitswei]

+1

[UbikZ]

+1

[emflores]

+1 page-break-inside: avoid is still not working as of 2.1.1

[kenkrige]

I am using 2.1.1 and "page-break-after: right" does not work. It is treated exactly like "page-break-after: always", which works fine.

[garykrige]

+1 page-break-after: right; also not working. @kenkrige and I need to print back to back reports and this feature is critical. page-break-after

[samwise-nl]

+1 also having a ton of trouble making a reasonable PDF document of a page and having the page-break css styling apply.

My solution so far has been to make PNG snapshots of our SVG charts (Highcharts), output them to the filesystem and then build a new local page in my phantomjs script. The page-break logic seems to work fine for actual images. However the scaling I need to do to fit it into a PDF makes it look not great and also the text and numbers is not selectable in the PDF (but it's a workaround that may help someone).

[ziyaaktas]

try using 2.1 or above. it works I think.

[samwise-nl]

@ziyaaktas I'm using 2.1.1 and it doesn't seem to fix things for me. We do have a lot of javascript generated DOM so that may be causing troubles, but I haven't been able to find a combo of things (viewportSize, paperSize, zoom, dpi ...) that makes my rendering work. Getting closer but definitely not the same as the HTML representation from firefox or chrome in print mode.

[emflores]

@samwise-nl We are also using 2.1.1 and experiencing this. Any updates on this one @ariya?

[mozgras]

+1 page-break-inside: avoid; not working on 2.1.1

[serpulga]

+1

[alex7egli]

+1 page-break-inside:avoid not working for me in phantomJS, but works in Chrome print preview of same page.

[kromit]

here is my workaround:

.page-break{
      page-break-before:always;
      page-break-inside:avoid;
      margin-top: 300mm; /*phantomjs renders it on the top of the next page*/
    }

I am using 300mm because DIN A4 page is 297mm high.

[ddiazpinto]

This feature is extremely important to make multi page documents well structured. :+1:

[kav]

+1

[drdla]

+1

[drdla]

A (working) workaround for page-breaks:

So PhantomJS has this bug which scales the page by 150% and requires you to scale it back to the desired size by applying a scaling factor of 0.666 (https://github.com/ariya/phantomjs/issues/12685).

When applying this scaling factor to the entire page (e.g. via body {zoom: .666} or body {-webkit-transform: scale(.666); transform: scale(.666); -webkit-transform-origin: 0 0; transform-origin: 0 0;}), page-breaks stop working. Because of the scaling, it just inserts some space after / before the element that should be on the next page.

How I got it to work is by applying zoom: .666 to all elements immediately below the body element and then fixing their width like so (I'm using section elements, but it should also just work with the general body > * selector):

body > * {
  width: 66.667%;
  zoom: .666;
}

[andrebaresel]

I'm working on this issue in our PDF engine now since months. First note for all: 1) the problem is only for MacOS and Linux phantomjs engine. There you get 133% scale. 2) on windows machines you don't need to do anything, it simply works without css tricks.

Thanks go to drdla the 'zoom' was the working solution. But, just set it to the body this is enough! body { zoom : 0.75 }

I'm pretty sure that it is factor 0.75. Because we print out tables with fixed size columns (e.g. 70mm) and I measured them on the printer.

PS) Before I used "transform", which was also ok until we introduced "page-break". The "Transform" breaks the page size calculation inside phantomjs completly, the page breaks occure somewhere at 75%.

Thanks go to drdla you saved my day.

PPS) to get the right Header and Footer you need to do the same trick. And remember they cannot access other resources, do everything inline.

PPPS) If someone has a hint for pagebreaks in table rows.

[omenking]

Setting the element and parent to position: relative; fixed elements that I wanted to page-break-inside:avoid;

[samwise-nl]

Has anyone given the new 2.5.0 beta build a test to see if the page-break rules are followed properly now? https://groups.google.com/forum/m/#!topic/phantomjs/AefOuwkgBh0

I'm trying to test my script but having other issues with it at the moment.

[IAMtheIAM]

Thanks @drdla and @andrebaresel , adding

  width: 66.6%;

to my container element fixed the scaling issue I was having with phantomjs rendering the page. :-) It was not necessary to use zoom: 0.666; - just setting the width as a percentage fixed it nicely. I was hardcoding and guesting it before.

Although, it still doesn't honor the page-break-before: always - it just ignores it :-/

[janlukasschroeder]

Thanks @drdla I changed your code a bit so that the final layout actually stays the same without being distorted:

body > * { width: 99.999%; zoom: .999; }

After adding the snippet above, I added the snippet below to all elements that should be unbreakable.

.unbreakable { page-break-inside: avoid !important; }

[skylarmb]

+1 on page-break-inside: avoid; not working on 2.1.1. None of the workarounds in this thread worked for me for tables.

[btoda]

Is this only happening on MAC?

[sandrinr]

@btoda No, for me this consistently happens with PhantomJs 2.1.1 on macOS and Linux (Ubuntu).

[juergengunz]

any updates on this?

[lezhangxyz]

We fixed this issue by adding float:none; to the element with page-break-inside: avoid;. Hope this works for everyone else.

[stale[bot]]

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!