MrJoky
November 27, 2025, 7:30am
1
When we switch to the documented approach using #header-html and #footer-html together with print_settings.repeat_header_footer, the header is only rendered on the first page and the footer only on the last page, not repeated on each page as expected.
My Setup
Header
{% if letter_head and not no_letterhead %}
{% if print_settings.repeat_header_footer %}
<div id="header-html" class="visible-pdf">
<div class="letter-head">
{{ letter_head }}
</div>
</div>
{% else %}
<div id="header">
{{ letter_head }}
</div>
{% endif %}
{% endif %}
Footer
{% if print_settings.repeat_header_footer %}
<div id="footer-html" class="visible-pdf">
{% if footer and not no_letterhead %}
<div class="letter-head-footer">
{{ footer }}
</div>
{% endif %}
<p class="text-center text-small page-number visible-pdf">
{{ _("Page {0} of {1}").format('<span class="page"></span>', '<span class="topage"></span>') }}
</p>
</div>
{% else %}
{% if footer and not no_letterhead %}
<div class="letter-head-footer">
{{ footer }}
</div>
{% endif %}
{% endif %}
Context information (for bug reports)
Output of bench version
bench v5.27.0
Steps to reproduce the issue
Create a custom print format for a multi-page document (e.g. long item table).
Place header and footer in
{% if print_settings.repeat_header_footer %}
<div id="header-html">
{{ letter_head }}
</div>
{% endif %}
Enable “Repeat Header and Footer” in Print Settings.
Print the document as PDF (using the built-in PDF button).
Observed result
Header only printed on first page. Footer printed on last and if content expands on a second page to new page.
Expected result
Header and footer should be placed in each page at top and bottom. Content should respect header and footer.
Additional information
ERPNext: v15.88.1
Frappe: v15.88.1
wkhtmltopdf: 0.12.6 (patched qt)
Already tried:
opened 03:21PM - 20 Dec 21 UTC
closed 01:03PM - 31 Jan 24 UTC
bug
### Information about bug
When trying to print a PDF from Quotation, Sales Or… der, or Sales Invoice, we are having the issue where the Header and Footer only show on the 1st page of the PDF, and not the subsequent ones even with the "Repeat Header and Footer in PDF" setting properly checked in Print Settings.
The issue appeared after we updated our Frappe and Erpnext version about a month ago via bench update to Ver. 13.15 We had not updated the instance for a while before that, so I can't remember exactly what build we were on, but it was still version 13.
We just updated again to ERPNext: v13.16.1 (version-13) and Frappe Framework: v13.16.0 (version-13), and the issue is still present.
We already tried fiddling with the print settings (turning off and then back on to repeat on every page). My programmer seems to think it’s a system bug that needs to be resolved by Frappe.
Can anyone confirm if it’s just us having this issue, or is it affecting everyone else on this version?
EDIT 1. 12/21/2021: We installed and brand new instance of Erpnext from scratch, and this issue is still present there. So we can confirm the issue relates to the build from Frappe, and not to anything particular or specific to our own instance.
Edit 2. 12/21/2021: We already tried all the suggestions in this link below but they don't fix the issue.
https://discuss.erpnext.com/t/header-footer-in-pdf-in-ver-13/76581/3
### Version
v13
### Module
selling
### Version
ERPNext: v13.16.1 (version-13)
Frappe Framework: v13.16.0 (version-13)
### Installation method
manual install
### Relevant log output / Stack trace / Full Error Message.
_No response_
### Code of Conduct
- [X] I agree to follow this project's Code of Conduct
opened 12:50AM - 03 Oct 24 UTC
bug
Hi there
I just spend the last 4 months trying to get print formats working the… way it's supposed and unfortunately encountered lots of issues. I dug deep into the rabbit hole, even created a custom Frappe app - but the problem relies deeper inside Frappe core.
## Encountered Issues
### 1. Global Frappe CSS is interfering with print format styles / default print format styles won't be applied
Various global styles will be applied onto the print format preview, which might lead to false expectations. As soon as the user switch over to "Full Page" or "PDF", those styles aren't applied anymore, resulting to a different layout.
<details>
<summary>Example Jinja 1</summary>
```
<p>
Will be small in preview, same size in Full Page view
</p>
<table>
<tbody>
<tr>
<td>This text will be larger in preview, but same size as text above in "Full Page" view</td>
</tr>
</tbody>
</table>
```
</details>
<details>
<summary>Example Jinja 2</summary>
```
<table>
<tbody>
<tr>
<td>
<p>Number 3 will be right in Preview, but inline in Full Page</p>
</td>
<td><b>3</b></td>
</tr>
</tbody>
</table>
```
</details>
### 2. Print Style is applied even if it is disabled
If you disable Print Style "Redesign", it will still be applied to prints. You need to replace or clean it within "Print Settings" too in order to really disable it. I guess that's not intended.
### 3. Bootstrap CSS renders inline CSS useless (in PDF or Print view)
I can't pinpoint the exact CSS rule within bootstrap.css, but some style settings will be ignored as soon as you try to generate a print. This happens even though there is no rule for the same element in it!?
<details>
<summary>Example Jinja</summary>
```
<table>
<tbody>
<tr style="color: red !important">
<td>This text will be red in preview and Fulle Page, but black in PDF and Prints</td>
</tr>
</tbody>
</table>
```
</details>
### 4. PDF and Preview doesn't look the same
I know it's wkhtmltopdf related and I already solved this issue with my custom Frappe app. But I still mention it here to support any native implementation of a more modern print engine.
-----
## Environment & tested Steps
### Environment:
- ERPNext: v15.37.0 (latest)
- Frappe Framework: v15.42.0 (latest)
- Docker setup
### Tested Steps
As mentioned, I'm already trying to get a solution since ~4 months - in order to get Frappe production-ready in our company. Several steps were part of that:
- Setup clean Frappe using Frappe docker -> no change
- Try to edit settings & print styles -> see findings in the issue section
- Replace wkhtmltopdf with different (custom) solution. -> working fine
- Dug into the source-code in order to create a valuable Issue and solve problems on our end in advance
## What are my expectations?
I don't take anything for granted because I know Frappe is FOSS and I really appreciate how far it has come. Howerver, I was still very surprised by the state of Print Formats. It seems like a little mess to me, some we were able to solve, some not. Print Formats should be clean from any CSS as far as possible (I know it's not that easy) and should be simple to use.
MrJoky
November 27, 2025, 12:41pm
2
So i found the “solution” (more an UI/UX-Issue than a bug)
The button PDF is the correct one which uses the wkhtmltopdf engine.
The Drucken (print) Button uses the browser to render the PDF. Because of this, every wkhtmltopdf part will not be read correctly.