text problems when generating multiple pages in PDF

[jurgen]

I'm using wkhtmltopdf to print out PDFs with images and some text below it. The images are generated with HTML5 on a page, this page is then converted to a PDF with the help of wkhtmltopdf. It works fine when there is 1 image on the page but when there are multiple images the text below the image dissapears. This can be tested on these links:

http://staging-web.matexi.be/nl-be/home/onze-projecten/detail/project_no/P0025/tab/living -> scroll to the bottom of the page and click 'Print een overzicht van alle loten' (sorry for the dutch). Wait a little bit and the generated PDF is shown. For this project all generates just fine.

http://staging-web.matexi.be/nl-be/home/onze-projecten/detail/project_no/P0040/tab/living -> now try this one and you will see that the page generates two plans and the text below the images is gone. 

http://staging-web.matexi.be/nl-be/home/onze-projecten/pdf/project_no/P0040/tab/living -> This is the page that is used to generate the PDF.

Can somebody help me with this problem? 

Kind regards,

Jurgen

[jurgen]

Maybe this error can help?

I'm testing with a console and there the same problem exists. I'm getting this error message:

Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This migth be an indication of an iframe taking to long to load.

I'm trying this command:

wkhtmltopdf.exe --no-background http://staging-web.matexi.be/nl-be/home/onze-projecten/pdf/project_no/P0040 c:\projects\example.pdf

Then I get the above error while the document is generated and when I look into the PDF the text is gone.

Op woensdag 23 april 2014 09:30:40 UTC+2 schreef jurgen:

[Yozons eSignForms]

I never saw any comment on this posting, but I too am having this problem when converting multiple HTML files at once.

My version: wkhtmltopdf 0.12.1 (with patched qt) on CentOS 6 I retrieved from wkhtmltox-0.12.1_linux-centos6-amd64.rpm

From the command line, the error (typos are as they were reported) shows up as:

Loading pages (1/6)
Counting pages (2/6)

Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This migth be an indication of an iframe taking to long to load.

Resolving links (4/6)
Loading headers and footers (5/6)
Printing pages (6/6)
Done

In my case, I'm trying to convert 4 HTML files into a PDF.  Each of the HTML files will convert fine to a PDF.  I am able to bundle any three of them and it will convert fine.  But when I add that fourth HTML file, the error crops up.  I also found that sometimes it runs okay. 

The error does not prevent a PDF from being generated, but it does render incorrectly, with images and a Google Font text not rendering at all (even though the font-family allows for a standard 'cursive' fallback font). 

I have uploaded a ZIP file containing the HTML files I was running, along with some PDF output. For the PDF output, note that the "signature" fields should have a blue Google Font called Pacifico along with images for radio buttons and checkboxes, and these are missing when the error occurs:

wkhtmltopdf --page-size Letter --encoding utf-8 --print-media-type --image-quality 100 --margin-left 5mm --margin-right 5mm --margin-top 5mm --margin-bottom 5mm Application.html Background.html HiringDecision.html Offerletter.html I-9.html 5.pdf
--> Had the warning and bad PDF

wkhtmltopdf --page-size Letter --encoding utf-8 --print-media-type --image-quality 100 --margin-left 5mm --margin-right 5mm --margin-top 5mm --margin-bottom 5mm Application.html Background.html HiringDecision.html Offerletter.html 4.pdf
--> Had the warning and bad PDF

wkhtmltopdf --page-size Letter --encoding utf-8 --print-media-type --image-quality 100 --margin-left 5mm --margin-right 5mm --margin-top 5mm --margin-bottom 5mm Application.html Background.html HiringDecision.html 3.pdf
--> Worked fine

wkhtmltopdf --page-size Letter --encoding utf-8 --print-media-type --image-quality 100 --margin-left 5mm --margin-right 5mm --margin-top 5mm --margin-bottom 5mm Application.html Background.html 2.pdf
--> Worked fine

wkhtmltopdf --page-size Letter --encoding utf-8 --print-media-type --image-quality 100 --margin-left 5mm --margin-right 5mm --margin-top 5mm --margin-bottom 5mm Application.html 1.pdf
--> Worked fine

Then I changed the file order just to be sure that the last added HTML files were not the source of the issue:

wkhtmltopdf --page-size Letter --encoding utf-8 --print-media-type --image-quality 100 --margin-left 5mm --margin-right 5mm --margin-top 5mm --margin-bottom 5mm Offerletter.html I-9.html EmergencyContacts.html 3-alt.pdf
--> Worked fine

wkhtmltopdf --page-size Letter --encoding utf-8 --print-media-type --image-quality 100 --margin-left 5mm --margin-right 5mm --margin-top 5mm --margin-bottom 5mm HiringDecision.html Offerletter.html I-9.html EmergencyContacts.html 4-alt.pdf
--> Worked fine once, then got the warning

[Yozons eSignForms]

Since I had a wkhtmltopdf command that sometimes worked and sometimes produced the warning, I watched the web server access log as I ran it.

When all worked well, I'd see requests like this:

99.244.75.4 - - [24/Nov/2014:15:38:21 -0800] "GET /TLCA/static/esf/radioSelect.png HTTP/1.1" 200 524 0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34
99.244.75.4 - - [24/Nov/2014:15:38:21 -0800] "GET /TLCA/static/esf/radioUnselect.png HTTP/1.1" 200 502 0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34

But when the warning was produced, nothing was reported, indicating wkhtmltopdf didn't succeed/make these requests.

I noted that the warning is reported multipageloader.cc: https://github.com/wkhtmltopdf/wkhtmltopdf/blob/master/src/lib/multipageloader.cc

And there are two issues already created that seem to reference the warning:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1865
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1531

I do know that each of the HTML files loads the same images and Google Font, so it could be related to requesting the same resource repeatedly.

The warning is interesting, too, in that it indicates something took took too long, but the error appears right away.

Lastly, when I ran it a few more times, I got it so that the warning appeared twice AND it exited with an error:

Loading pages (1/6)

Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This migth be an indication of an iframe taking to long to load.
Counting pages (2/6)
Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This migth be an indication of an iframe taking to long to load.
Resolving links (4/6)
Loading headers and footers (5/6)
Printing pages (6/6)
Done

Exit with code 1 due to network error: ProtocolUnknownError

This is interesting only in that I ran it one more time, and then got no warnings or errors.  It's very odd to have a program that gives different results when run multiple times with the same input (and command arguments).

There does not seem to be any real difference in actual times of the runs, either, since this is the output from 'time' on the commands:

'time' on a successful run:
real    0m8.312s
user    0m6.974s
sys     0m1.188s


'time' on the warnings run:
real    0m8.231s
user    0m6.890s
sys     0m1.212s

[Yozons eSignForms]

Just for grins, I tested using wkhtmltopdf 0.11.0 rc1 and I could not reproduce the warning/error.

And it runs much faster too.  When converting 5 HTML files using 0.11.0 rc1, 'time' shows:

real    0m1.672s
user    0m1.517s
sys     0m0.170s

Compared to the same 5 HTML files being converted by wkhtmltopdf 0.12.1 (with patched qt), 'time' shows:

real    0m8.220s
user    0m6.924s
sys     0m1.173s

That's nearly 5 times slower with the latest version.  The "Printing pages (6/6)" appears to be where the main extra time comes from.  Unfortunately, the previous version does not support WOFF, though it ran fast.  Also, adding HTML files seemed to make little difference to the overall speed.  The 0.12.1 version seemed to take an extra second or so as additional HTML files are included.

The "good" news is that I don't see that warning/error when I added the command line option: --javascript-delay 500

I'm not sure why, though, since my HTML pages really have no javascript (and --no-stop-slow-scripts does not resolve it).  At 400, it seemed to work frequently, but I could still make it report the warning after 5-10 attempts.  At 500, my test cases could not reproduce the warning that causes the PDF to be incorrect.