When using custom print format page breaks are showing in print preview but do not break the page when printed or saved as PDF. Page breaks that show where they have been checked in item break correctly. Have tried every suggestion I have found in the forum and nothing has worked.
Any help would be appreciated.
Johnny Taylor
This is the setup we are running:
ERPNext: v6.21.5
Frappe Framework: v6.22.7
on Ubuntu 15.10
I don’t think this is possible out of the box.
You should make your own Print Format in HTML
Is there a template of the HTML and CSS anywhere so we would have a place to start in building a custom print format?
Have done that and many other things but they do not break when the page is printed or saved as a PDF.
Does this work for you in the ERPNext version you are running?
Is there any progress on this? Running ERPNext: v10.0.14 (master), Frappe Framework: v10.0.15 (master) and wkhtmltopdf 0.12.3 (with patched Qt) we observe exactly the same issue (the page break is shown in the preview, it works when using the browser print on e.g. PdfCreator, but the built-in pdf fails to create page breaks where requested.
To check the capability of wkhtmltopdf, I have processed this file
<html>
<head><title>page break</title></head>
<body>
<h1>Page 1</h1>
<h1 style="page-break-before: always;">Page 2</h1>
</body>
</html>
This will nicely convert into a two page pdf when running wkhtmltopdf page_break.html page_break.pdf. Running exactly the same html content from outside ERPNext will not do the page breaks. I have also tried the <div class="page-break"></div> option, same result.
Update: when trying to get the html from Frappe to do page breaks, it turns out these two divs prevent the page breaks in wkhtmltopdf:
<div class="row section-break">
<div class="col-xs-12 column-break">
They surround the actual content block. When commented out, the pdf has breaks where expected (using both breaking options mentioned above). So, uncommenting the following two lines in frappe/templates/print_formats/standard.html
<!-- <div class="row section-break"> -->
(...)
<!-- <div class="col-xs-{{ (12 / section.columns|len)|int }} column-break"> -->
(...)
<!-- </div> -->
(...)
<!-- </div> -->
has turned the pdf function to do page breaks nicely… Are these divs used for anything? Or could they be removed… (preview still works as expected)
I find the same results.
I have now resorted to using custom print formats only, and that works just nicely 
Except for the page margins, where a PR is still open (using regex instead of soup to parse pdf page margins by lasalesi · Pull Request #4973 · frappe/frappe · GitHub)
what do you mean by custom print formats only? Meaning in your custom app, you have it generating the PDF for full customizations? Or are all your edits done via the site, in the “print-format-builder” ?
Selecting “custom format” on the print format page will hide the drag&drop style format builder and provide a blank html input. With this, the complete format can be defined.
Doing this will work around the issue described above.
I have been doing some tests successfully to understand the page breaks properly.
Your HTML code when run as Custom Print format on ERPNext v12, then the Print button used, will render properly the page breaks. Your HTML code, saved to a standalone file, on a MAC running OS X, with wkhtmltopdf 0.12.3 AND wkhtmltopdf 0.12.5 converted with the terminal command:
wkhtmltopdf page_break.html page_break.pdf
However, no success has been obtained running your HTML code as Custom Print format on ERPNext v12, then generating a PDF from the print dialog.
I personally prefer coding my own HTML and CSS to structure page sizes, etc. and have had limited success with different page sizes, and even locating Jinja rendered elements in specific places on the page (Xmm, Ymm).
I still have some questions:
What specific HTML code allows us to work around the issue, so that the page breaks work using BOTH the Print button and the PDF button in the Print Dialog?
What is the best model (html + Jinja + CSS) to render page breaks automatically as content fills up the page? This is especially useful in multi-page print formats or reports where depending on the amount of data contained for that specific instance, the page numbers will not be fixed.
[EDIT] Solution found here, thanks to @Ratanak :
So far, this code has worked well using Print button in dialog, direct to PDF or printer from Chrome. Selecting Print Using System dialog or PDF renders margins around it (the zoom bug) and the PDF feature from wkhtmltopdf renders one page OK, the others a mess.
<div class="print-format">
{% set pages = ['1','2','3','4','5'] %}
{% for page in pages %}
<div class="simple-header">HEADER</div>
<div class="simple-body">
<h1>Jinja and CSS Tests</h1>
{{ lorem(5) }}
<br>
</div>
<div class="simple-red-footer">FOOTER</div>
</div>
<div class="page-break"></div>
{% endfor %}
For now, this code renders the divs in proper size. Page breaks are doing OK. And page breaks are being triggered when enough data has filled the specific table or page size.
[EDIT] After some moderate coding, I found that if you want extremely consistent results, you should be from “hardcoding” the page breaks in the print format HTML. This means that you must parse the pages and structure with a call to a custom python function made available to the jinja environment vía hooks.py, pass the necessary arguments, such that you get proper results regardless of whether you have a document (sales invoice, quotation, etc.) with 1 item or 1000 items. The function shoul return the html already assembled. Problem solved.