Your trouble is caused by the negotiation of user permission between the filesystem, xvfb-run wkhtmltopdf and headless X11 server.
The User runs this command:
cd /home/user;
touch somehtml.html;
/usr/bin/xvfb-run --server-args="-screen 0, 1024x768x24"
wkhtmltopdf somehtml.html preview.pdf;
wkhtmltopdf produces a Warning:
Warning: Failed loading page
file:///home/user/somehtml.html (ignored)
The target PDF file doesn't exist, has missing content from somefile.html or is blank.
How to reproduce the problem, an sscce:
Conditions:
64 bit Fedora Linux 17, PC Desktop
Install via a 'sudo yum install wkhtmltopdf'
wkhtmltopdf has version 0.10.0
From a terminal, using xvfb-run
The offending HTML in somehtml.html:
<html>
<head>head tag</head>
<body>
<h1>this should be H1<h1>
Words words words in a paragraph.
</body>
</html>
Be in a user's directory and run
cd /home/user;
/usr/bin/xvfb-run --server-args="-screen 0, 1024x768x24" wkhtmltopdf /home/user/somehtml.html /home/user/preview.pdf
wkhtmltopdf produces a warning
Warning: Failed loading page
file:///home/user/somehtml.html (ignored)
/home/user/preview.pdf is missing or blank.
What is causing the problem:
Your xvfb-run jails wkhtmlpdf to the user and doesn't have permission to read and or write to /home/user/somehtml.pdf or /home/user/preview.pdf
To see if this is your problem, ask xvfb-run what kind of permissions we have?
/usr/bin/xvfb-run --server-args="-screen 0, 1024x768x24" whoami > /tmp/secret.txt; cat /tmp/secret.txt
Workaround:
/tmp typically has looser permissions than /home/user/, so do all your work inside /tmp
cd /tmp;
touch /tmp/somehtml.html;
#put above html in somehtml.html
cat /tmp/somehtml.html
<html>
<head>head tag</head>
<body>
<h1>this should be H1<h1>
Words words words in a paragraph.
</body>
</html>
/usr/bin/xvfb-run --server-args="-screen 0, 1024x768x24" wkhtmltopdf /tmp/somehtml.html /tmp/preview.pdf
And you should get this stdout:
loaded the Generic plugin
Loading page (1/2)
Printing pages (2/2)
Done
And preview.pdf
![chrome_wkhtmltopdf_and_xvfb-run]()
Why is not wkhtmltopdf smarter and handling this problem for me?
This is harder than it looks, because wkhtmltopdf has to contend with hostile 3rd party proprietary PDF rendering software (made by adobe?) and they work in concert with browser developers to obfuscate and make access to their engines hard because many large corporations by them money for their top secret source code. wkhtmltopdf is pricking into that world so that open source people can have it without paying suits in tall office buildings cash money. That's why adobe pay money to developers of browsers to make this hard for us. We are diluting their profit mechanism, so they retaliate by throwing stop sticks at us where they can. This is that. The more we spreads this round the world to novices, the harder the 3rd party throws stop sticks, since you are preventing profit in others.
