Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random header dissapearence #2083

Closed
0lukasz0 opened this issue Dec 1, 2014 · 36 comments

Comments

@0lukasz0
Copy link

commented Dec 1, 2014

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

This comment has been minimized.

Copy link
Member

commented Dec 4, 2014

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

@ashkulz ashkulz closed this Dec 4, 2014

@ashkulz ashkulz added the Invalid label Dec 4, 2014

@0lukasz0

This comment has been minimized.

Copy link
Author

commented Dec 5, 2014

@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

This comment has been minimized.

Copy link
Member

commented Dec 5, 2014

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

@0lukasz0

This comment has been minimized.

Copy link
Author

commented Dec 5, 2014

@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

This comment has been minimized.

Copy link
Member

commented Dec 7, 2014

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

This comment has been minimized.

Copy link
Author

commented Dec 10, 2014

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

@0lukasz0

This comment has been minimized.

Copy link
Author

commented Dec 18, 2014

@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

This comment has been minimized.

Copy link
Author

commented Jan 5, 2015

@ashkulz any update on this issue?

@ashkulz

This comment has been minimized.

Copy link
Member

commented Jan 6, 2015

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)

@ashkulz ashkulz reopened this Jan 6, 2015

@ashkulz ashkulz removed the Invalid label Jan 6, 2015

@0lukasz0

This comment has been minimized.

Copy link
Author

commented Feb 11, 2015

@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

This comment has been minimized.

Copy link

commented Mar 3, 2015

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

This comment has been minimized.

Copy link

commented Mar 12, 2015

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 0lukasz0 changed the title Blank pages and random header dissapearence Random header dissapearence Mar 13, 2015

@0lukasz0

This comment has been minimized.

Copy link
Author

commented Mar 13, 2015

@ashkulz can we have any info on this issue?

@jturbide

This comment has been minimized.

Copy link

commented Apr 16, 2015

@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

beledouxdenis added a commit to odoo/odoo that referenced this issue Apr 24, 2015

[FIX] report: random disappearance of headers/footers
This issue is related to the wkhtmltopdf issue
wkhtmltopdf/wkhtmltopdf#2083

It seems there is a race condition in the Javascript file
loading in wkhtmltopdf 0.12.x.

The subst.js file put in the header/footer of reports
was not always loaded when the page was being rendered,
leading to the crash of the onload="subst()" attr in
the body node, leading to the non-rendering
of the header/footer.

Replacing the script file by its content solves
the issue.

Increasing the --javascript-delay of the wkhtmltopdf
executable (e.g. 1000 ms instead of 200 ms,
the default value) seems to solve the problem
as well, but will lead to obvious performance issues.

We therefore choose to put the javascript code inline,
as a workaround,
the time the issue is solved in wkhtmltopdf, at least.

closes #3047,#5548,#6207
opw-633161
@odony

This comment has been minimized.

Copy link

commented Apr 24, 2015

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

This comment has been minimized.

Copy link

commented Apr 27, 2015

@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

This comment has been minimized.

Copy link
Member

commented May 17, 2015

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

@0lukasz0

This comment has been minimized.

Copy link
Author

commented May 19, 2015

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

This comment has been minimized.

Copy link

commented May 19, 2015

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

This comment has been minimized.

Copy link

commented May 19, 2015

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

This comment has been minimized.

Copy link

commented Jun 10, 2015

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

This comment has been minimized.

Copy link

commented Jun 10, 2015

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

This comment has been minimized.

Copy link
Member

commented Jun 22, 2015

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

@odony

This comment has been minimized.

Copy link

commented Jun 22, 2015

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

@ashkulz

This comment has been minimized.

Copy link
Member

commented Jun 22, 2015

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

This comment has been minimized.

Copy link

commented Jul 8, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 8, 2015

@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

This comment has been minimized.

Copy link
Member

commented Jul 14, 2015

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

This comment has been minimized.

Copy link

commented Oct 4, 2016

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

This comment has been minimized.

Copy link

commented Jun 8, 2017

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

@jeff-h

This comment has been minimized.

Copy link

commented Jun 9, 2017

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>).

@alloylab alloylab added the NeedInfo label Jun 15, 2018

@Tomsgu

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2018

Can you still reproduce the problem on 0.12.5?

@VenkateswaranCGI

This comment has been minimized.

Copy link

commented Aug 2, 2018

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

@jturbide

This comment has been minimized.

Copy link

commented Aug 2, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2018

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

@Tomsgu Tomsgu closed this Aug 22, 2018

@Tomsgu Tomsgu removed the NeedInfo label Aug 22, 2018

@hrishikesh

This comment has been minimized.

Copy link

commented Dec 5, 2018

@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

JKE-be added a commit to odoo-dev/odoo that referenced this issue Dec 7, 2018

[FIX] web: remove report_assets_common JS from minimal_layout
This assets has a lot of JS that is loaded by wkhtmltopdf without any reasons.
Wkhtmltopdf don't like long js to load (it is why subst has been write inline)

This commit allow to print again (on slowly server) several documents in the
same pdf. Before this commit, the JS was not loaded before the default js-delay
and so the subst function never called with as result a pdf of only 1 page.

After this commit you can again print several documents in the same pdf and
subst function is applied.

opw-1909000

courtesy of @beledouxdenis that help to debug this error since it is only
reproductible on paas server.

This commit follow the same logic that commit odoo/odoo@3c61ee5
And issue wkhtmltopdf/wkhtmltopdf#2083 is not yet fixed

robodoo pushed a commit to odoo/odoo that referenced this issue Dec 12, 2018

[FIX] web: remove report_assets_common JS from minimal_layout
This assets has a lot of JS that is loaded by wkhtmltopdf without any reasons.
Wkhtmltopdf don't like long js to load (it is why subst has been write inline)

This commit allow to print again (on slowly server) several documents in the
same pdf. Before this commit, the JS was not loaded before the default js-delay
and so the subst function never called with as result a pdf of only 1 page.

After this commit you can again print several documents in the same pdf and
subst function is applied.

opw-1909000

courtesy of @beledouxdenis that help to debug this error since it is only
reproductible on paas server.

This commit follow the same logic that commit 3c61ee5
And issue wkhtmltopdf/wkhtmltopdf#2083 is not yet fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.