html2pdf.js: 0.9.1: I can't make the page-break options work at all
I have tested all the combinations of options with the same result: the pages break wherever they needs to, regardless the avoid
settings or mode, the CSS properties and so on. The DOM flows across the page break.
If using legacy code to force break the page, the next element is moved to the next page break and then split too!! Leaving a blank page behind…
I’ve seen the PRs and others issues about the same subject, but no movement since 0.9.1 was released, more than a month ago, and in my project at least, this feature is plainly broken 😞 . Everything worked OK for me till I needed a multipage export, now I’m totally lost.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Comments: 23 (6 by maintainers)
Have you tried anything like:
That’s specifically telling it to avoid breaking across a table row - the “modes” are only one small part of what the pagebreak functionality can do. That said, tables are tricky and don’t behave like most other elements, they may still need some work.
Hi @AbelVM @foria, things move a bit slowly here, you’ll have to bear with me. As I see it there’s three possible issues here:
Page breaks aren’t working for you at all. Is this the case? Try out this test Fiddle, which showcases all the different kinds of page-breaks you can use.
Pages break in the middle of text when you have elements longer than one page. This is a more complicated issue that there’s no fix for currently, but the vast majority of page-break needs should have been resolved with v0.9.1.
Something else? If it’s not one of the two above, give me an example so I can reproduce it and see what’s going on.
Thanks!
UPDATED Solution from my last response:
I solved on my projects using this options:
I had a 60 pages PDF, so i divide my PDF into sections and break after each section.
The other problem i had was those super long text’s I used this class for those super text’s, in order to break if text was too long.
Just to comment here, because my experience might help. I also had issues with the page breaks. My document was about 15 pages long. I discovered the pixel limitation on the canvas size was the main issue. It worked much better when I chained sending individual sections/divs to the canvas, creating a new page in the PDF, and saving the whole PDF at the end.
Hi @eKoopmans , I’ve played with that example before, it works flawless but looks like it’s not applicable on my end.
I’m working with dynamically generated tables (with head and body), and any available combination of page break related options leads to undesirable results. My first case has 4 DIVs (1st with some charts, the rest with tables):
I can’t recall now all the tests I’ve performed, but I can assure you I spent a lot of time testing all the different combinations I could imagine with no result but hundreds of failed PDFs in my download folder 😝
@eKoopmans, Can it work in flex div as well, Currently i am facing issue with line split into two pages.
Is there a way we can fix this, i’m using v0.9.1?
@eKoopmans thank you so much for providing this awesome library.
I think that the running count for the height of pages for a PDF exporting tables is off by a couple of pixels.
pagebreak: {avoid: 'tr'}
runs really great until around page 13 - 15 for us. At that point the top line gets cut off, and with each subsequent page it’s cut off a tiny bit more.To fix this we employed manual page breaks. Here are our settings:
pagebreak: {mode: 'css', after: '.avoidThisRow'}
Then we got the height of the exported letter-sized PDF from here: https://github.com/MrRio/jsPDF/blob/master/docs/modules_html.js.html#L728 Since we’re always exporting in landscape, the height was 612. We then multiplied that by 1.33333, since that’s the point-to-pixel conversion.
We then looped through our table and kept a running count of the height. When the running height total exceeded 612 * 1.3, we added the avoidThisRow class to the previous TR. To offset the library’s page height calculations, we’d add a padding of ((numberOfPages - 1) * 2) + 8 to the top of the current row. We’d then reset our running height count to 0 - (numberOfRows / 40). Right now I’m not sure why we didn’t employ the same math for the padding and starting height.
Yeah, this is quite a gizmodic solution. So far it seems to work. I’m posting this so that it may help with somebody else with this issue, or possibly eventually help towards a fix to the library.
Thank you again for this crazy wicked awesome library. It was crucial for a feature we just built.