Random header dissapearence

[0lukasz0]

Since update to 0.12 (now i'am using 0.12.2-dev-5dea253 - 64bit) we got wird behavior, some pages appear after last page and are blank, some pages are missing their headers.

I created gist with sample code: https://gist.github.com/0lukasz0/7b21ec0636b6a879ca6e. I tried using those command lines without margin and header spacing but problems are still there.

[ashkulz]

Please post actual HTML/CSS which can be run directly, it looks you are posting some .NET markup.

[0lukasz0]

@ashkulz actuall html has no sense, it's totally dynamic - always sometinhg else, i will post sample header and "body" in gist anyway, but I thing it has no use.

Plese reopen and further investigate issue, I have new clue: it seems that blank pages has the same page numbers as previous page.

[ashkulz]

I can't investigate anything unless you post actual HTML/CSS.

[0lukasz0]

@ashkulz I will post actual html in spare time, but I was investigating those issues, I found out what was the cause of blank pages, in v0.12 there was change in wkhtml behaviour regarding page-brak-after:

<div style="page-break-after: always; display: block; clear: both"></div>

earlier if there was no content after this there were no additional page rendered, now it renders page regardless whether there is additional content or not.

[ashkulz]

Well, that is what you are requesting with your CSS (page-break-after: always) -- the updated WebKit engine in 0.12.x (compared to earlier versions) respects your markup 😄

[0lukasz0]

@ashkulz I have updated gist with sample actual html (all markup is there).

[0lukasz0]

@ashkulz nothing I do seems to help with headers disappearing issue, I confirmed that removing --margin-top and --margin-bottom has no impact (maybe it's disappearing less often, but it's random so who can tell?).

[0lukasz0]

@ashkulz any update on this issue?

[ashkulz]

Didn't get a time to investigate this, won't happen for a month (releasing 0.12.2 and making alpha release for 0.13)

[0lukasz0]

@ashkulz we have confirmed that header are being rendered corectlly and all requests (for headers) contains data, someting happens during building page from main content and header. I have theory that it could have someting in common with header disapearing when header is prepended with whitespaces - it could be some wierd encoding issue, something could be added before page. I double checked and all our pages are using UTF-8 encoding, but we do use some coulture specific chars in text.

When can we expect some update on this issue?

[mohamedazher]

Hi,

I can say that i have almost the exact same issue. When using header-html and footer-html, i see that either the header or the footer goes missing (sometimes both) when the the PDF is loaded.

Its like 1st load, there is no header/footer, on 2nd load, only footer appears, 3rd load, both header and footer appear, 4th load only header, 5th, 6th, 7th works fine.

I dont see any blank pages, the main content always seems to load fine, but the header and footer html just work randomly.

As 0lukasz0 metioned, it does look like an issue when building the page. The header/footer or both are missed out in the page building at random.

Also to point out, i have an external css link in the header and footer html. Not sure if it matters.

[wall-s]

I have been having the same issue. In my header/footer HTML files I used external javascript and CSS files, linked using absolute URL's; the header/footer renders sometimes when using these, but not always. I'm using externals in the main content as well (using absolute URL), no problem there.

I decided that I would test that this was the problem by moving all of my data from the external files and just putting them directly in the HTML file. The problem seems to have resolved itself.

Why might wkhtmltopdf be having problems with linked files in the header/footer? Does it have to do with the use of absolute URL's to link CSS/JavaScript?

[0lukasz0]

@ashkulz can we have any info on this issue?

[jturbide]

@0lukasz0 @wall-s I faced the exact same problem, some of my assets (css/js) were missing on my main page and that is what caused my header and my footer to randomly disappear. I had some randomly strange issues and I feel like when there's an error with the JS wkhtmltopdf becomes high as hell

[odony]

We've been having a similar issue (using 0.12.1): we were loading an external file subst.js in both our headers and footers. This file contains a common subst() function to put page numbers in header/footer. The results were random for the footer on documents with several pages: the whole footer was sometimes missing, and sometimes present on some pages, without changing anything, just reprinting the document.

It seems to be related to some kind of race condition, where the external JS file is not fully loaded when the footer is rendered. Perhaps this caused a JS error when the body.onload="subst()" was executed without the file loaded, or perhaps it was still waiting for the file and the DOM was not ready at all.
With 0.12.2.1, the problem is worse: external JS files seem not to be loaded at all (see #2183)

In either case we found we could work around the problem in two manners:

• Either by passing a longer --javascript-delay option to wkhtmltopdf, probably giving a better chance of having the subst.js file loaded when the rendering takes place. (Default delay is 200, it started working for us with 250ms, but your mileage may vary). This works for 0.12.1 at least (probably not for 0.12.2.1)
• Or by removing the external JS file and putting the declaration of the subst() function in the header/footer source directly, making sure it is always loaded. (This works in 0.12.1 and 0.12.2.1)

I haven't delved further in the source code to see how --javascript-delay is implemented and if there is possibly another way for wkhtmltopdf to know when a document is fully loaded, before rendering it. Maybe @ashkulz can shed some light on this?
Were there any commits between 0.12.1 and 0.12.2.1 that could have modified the synchronization/loading of external JS files?

BTW, there seem to be many other issues related to the same or a similar problem: #2284, #2269, #2183, perhaps #2307 and others..

[hbto]

@odony & @ashkulz
This workaround kind of works with reports to be printed that do not exceed 500 pages
around that number report does not bear header neither footer.

So inline script is being got rid somehow when printing too many pages.

Best Regards

[ashkulz]

An example HTML/JS along with command-lines which fails some of the time would help me debug the issue.

[0lukasz0]

I updated gist with js which is generated, but to be honest I am sure problems do happen event without those javascripts (in my case they are generated and added to page if tokens like page or topage are used)

[oniietzschan]

I've been having the same issue in wkhtmltopdf 0.12.2.1. I'm using --header-html and --footer-html. Right around page 500 (always within 5 pages of 500) both the footer and header stop appearing for me.

My footer uses javascript and the subst() function (declared in footer.html directly) to display the current page number and max page count. My header is static html and does not use javascript.

--no-stop-slow-scripts and --javascript-delay aren't making a difference for me. I've had 1000+ page PDFs on occasion generate fine with these options omitted, and I've had the headers and footers disappear when using absurd values like --no-stop-slow-scripts --javascript-delay 60000.

[oniietzschan]

An update, I don't think the issue with >500 page PDFs has anything to do with JavaScript. I got rid of my footer.html (which used javascript for subst()) and replaced it with --footer-left. I'm still using a static header.html. There is no longer JavaScript used anywhere in my HTML document.

Now it gets to page ~1000 (as before, always at almost exactly at this number) before the header ceases to appear. The footer, generated with --footer-left, does not disappear ever.

It's almost as if wkhtmltopdf is able to include 1000 HTML headers/footers combined before it runs into some problem?

[hbto]

In order to resolve issue regarding 500 pages,

configure:
/etc/security/limits.conf

add these lines

•            soft    nofile          4096
  

•            hard    nofile          4096
  

and:

/etc/pam.d/common-session
and
/etc/pam.d/common-session-noninteractive

add this line

session required pam_limits.so

Best Regards.

[odony]

Thanks @hbto! So in this case the problem simply comes from the default OS limits in terms of open files. wkthmltopdf probably keeps an open file for each rendered page, so rendering huge documents can make it reach the OS limit.
Note that if you don't want/need to use pam_limits, you could also simply add ulimit -n 4096 or any other appropriate value in the startup script of your program executing wkhtmltopdf. This would work e.g. for Odoo, which is one example of a program that can trigger this bug.

[ashkulz]

@odony: e02ff7e essentially made --javascript-delay default to zero for headers/footers, which exposed the underlying problem much more severely.

[odony]

@ashkulz Thanks for the extra info! Is there any patch available to avoid this side effect of e02ff7e?

[ashkulz]

I'll be pushing a fix which will bring back the 0.12.1 behavior, but according to odoo/odoo@3c61ee5 it sometimes doesn't work for that version as well.

[jeff-h]

I too have this issue. My theory is that it's related to the inclusion of any external JS or CSS resource.

I can cause this randomness easily. I used the sample header.html from http://wkhtmltopdf.org/usage/wkhtmltopdf.txt. Simply adding the following immediately after the head tag is enough to cause the problem.

    <link type="text/css" rel="stylesheet" href="pdf-footer.css" media="all">

If I move this CSS inclusion after the <script> tag the problem goes away completely. Likewise, if I include the CSS directly in a style tag in the head then the problem goes away, both symptoms making me think this is a loading / timing issue.

Since I wanted jQuery in mine (yeah, I know...) it was the same story again.

The fix for me, since I'm using gulpjs, was to use gulp-inline (https://www.npmjs.com/package/gulp-inline/) which pulls any referenced CSS & JS files inline into the HTML document, meaning no other resources have to be loaded with the file. This is working perfectly for me so far.

[ashkulz]

@jeff-h: it is, see the related issue which was fixed. I'm keeping this open to track why the css/js doesn't get loaded even though page is reported as loaded.

[ashkulz]

A preview for the next release 0.12.3-dev-79ff51e is available, which should contain a partial fix for this issue.

Please note that the above downloads will be removed after the 0.12.3 release.

[mrkmg]

I was having the same problem, and increasing the javascript-delay from 200 to 400 fixed it.
I have no external javascript. Only the example subst function in the docs for page numbers.

[joantune]

@jeff-h: you shouldn't have CSS after the tag, right?

[jeff-h]

It was a long time ago, but I'm pretty sure I was talking about the opening head tag (<head>), not the closing tag (<\head>).

[Tomsgu]

Can you still reproduce the problem on 0.12.5?

[VenkateswaranCGI]

Wkhtmltopdf vs Reportlap
Which is the best tool and provide advise.

[jturbide]

Reportlab isn't free, and (RML) Report Markup Language™ is an XML-style language created by ReportLab.
WkHtmlToPdf or WkHtmlToImage both works by crawling your HTML page directly using webkit.

[Tomsgu]

Closing as this seems to be resolved. Please let us know if the issue persists in 0.12.5 version.

[hrishikesh]

@ashkulz, @Tomsgu :
I am getting exactly the same issue, Getting random blank pages for same HTML content on version 0.12.5

Here is the command

/usr/bin/wkhtmltopdf --encoding 'UTF-8' --margin-top '30mm' --margin-bottom '25mm' --footer-html '/var/www/stage/shared/tmp/tempWkhtmltopdfFiles/tmp_WkHtmlToPdf_6i05TI.html' /var/www/stage/shared/tmp/tempWkhtmltopdfFiles/tmp_WkHtmlToPdf_6jnmOi.html /var/www/stage/shared/tmp/tempWkhtmltopdfFiles/tmp_WkHtmlToPdf_7V7q0R.html --header-spacing '20' --header-html '/var/www/stage/shared/tmp/tempWkhtmltopdfFiles/tmp_WkHtmlToPdf_UezXoA.html' /var/www/stage/shared/tmp/tempWkhtmltopdfFiles/tmp_WkHtmlToPdf_Lvm0fr.html --header-spacing '20' --header-html '/var/www/stage/shared/tmp/tempWkhtmltopdfFiles/tmp_WkHtmlToPdf_iR0MC9.html' /var/www/stage/shared/tmp/tempWkhtmltopdfFiles/tmp_test-blank5.pdf

[grpanic]

Still an issue.
Ubuntu 20.04
It seems that it cannot render reliably --header and --footer
If --footer is exluded then --header seems to work reliably
If --header is excluded then --footer works
Seems to be affected also by file size?