Reputation: 877
I am trying to use Headless feature of the Chrome to convert a html to pdf. However, i am not getting output at all. Console doesn't show any error as well. I am running below commands in my windows m/c.
chrome --headless --disable-gpu --print-to-pdf
I tried all the various options. Nothing is being generated. I am having chrome version 60
Upvotes: 17
Views: 30830
Reputation: 7969
Update 2024:
You need to use this, or else it won't work now (2024)
--headless=old
So the full command line will look something like this:
chrome.exe --headless=old --disable-gpu --print-to-pdf="D:\my folder\a.pdf" "https://www.google.com"
Upvotes: 0
Reputation: 11736
For Windows Users (and others with MSEdge) a similar function is provided by MSEdge --headless, In addition version III+ has "With Acrobat" render.
Old answer was a suggestion to use MS Edge. However with version 128 onwards that is failing to function. So latest recommendation is use chrome-headless shell. See "New Answer" below.
NOTE still as at Version 112 Edge does NOT respect headless=new.
Newer --switches can be found at https://peter.sh/experiments/chromium-command-line-switches/
Currently MSEdge uses --headless commands as if "new" thus use the newer -header syntax, --headless --no-pdf-header-footer
will also not write the footer.
There is NO NEED to set a profile but you can via
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --profile-directory=c:\whateverUneed --headless blah blah
There should be no need to use any GPU hotfix those were resolved in Windows 5 years ago
So the normal everyday command can be where CWD is any path to a Current Working Directory
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --headless --no-pdf-header-footer --print-to-pdf="c:\CWD\google.pdf" "https://google.com"
Use "Chrome Headless Shell" it is much faster and lighter (and simpler). Here using current 32bit Windows, works on both 32bit and 64bit Windows.
Helper script (download.cmd). Replace both 32
with 64
if you wish.
set "download=chrome-headless-shell-win32.zip"
set "variant=win32/%download%"
curl -o LATEST_RELEASE_STABLE.txt https://googlechromelabs.github.io/chrome-for-testing/LATEST_RELEASE_STABLE
set /p version=<LATEST_RELEASE_STABLE.txt
curl -O https://storage.googleapis.com/chrome-for-testing-public/%version%/%variant%
tar -xf %download%
Invocation for this page
chrome-headless-shell --no-pdf-header-footer --print-to-pdf="%cd%\Stackoverflow 46074235.pdf" https://stackoverflow.com/questions/46074235/headless-chrome-to-print-pdf
Upvotes: 4
Reputation: 37947
By default, --print-to-pdf
attempts to create a PDF in the User Directory. By default, that user directory is where the actual chrome binary is stored, which is the specific version folder for the version you're running - for example, "C:\Program Files (x86)\Google\Chrome\Application\61.0.3163.100". And, by default... Chrome is not allowed to write to this folder. You can watch it try, and fail, by adding --enable-logging
to your command.
So unfortunately, by default, this command fails.*
You can solve this by either providing a path in the argument, where Chrome can write - like
--print-to-pdf="C:\Users\Jane\test.pdf"
Or, you can change the User Directory:
--user-data-dir="C:\Users\Jane"
One reason you might prefer to change the User Directory is if you want the PDF to automatically receive its name from the webpage; Chrome looks at the title tag and then dumps it like <title>My Page</title>
=> My-Page.pdf
*I think this default behavior is super confusing, and should be filed as a bug against Chrome. However, apparently part of the Chrome team is outright opposed to the mere existence of this command line option, and instead believe it would be better to force everyone using it to get a node.js build going with Puppeteer and the flag removed outright.
Invoking chrome in this way will work fine for example in a local dev env on IIS Express with Visual Studio, but it will fail, even in headless mode, on a server running IIS, because IIS users are not given interactive/desktop permissions, and the way chrome grabs this PDF actually requires interactive/desktop permissions. There are complicated ways to provide those permissions, but anyplace you read up on how begins with DON'T PROVIDE INTERACTIVE/DESKTOP PERMISSIONS. Further, the above risk of Chrome one day getting rid of the command-line makes working even harder to get it working an iffy proposition.
Judging by the source code, the Chrome team either used or based its work off of wkhtmltopdf. I haven't tried it but it's likely this will get the job done. The one minor risk is that when producing PDFs in Chrome, testing is obvious: View the page in Chrome. Open Print Preview if you're nervous. In wkhtmltopdf, it's actually a different build of Chromium, and that may produce rendering differences. Maybe. As a Community user noted, wkhtmltopdf was archived by the owner on Jan 2, 2023.
Another alternative is to get ahead of the group looking to get rid of --print-to-pdf
and use the browser dev API (via Selenium) as they prefer.**
private static void pdfSeleniumImpl(string url, string pdfPath)
{
var options = new OpenQA.Selenium.Chrome.ChromeOptions();
options.AddArgument("headless");
using (var chrome = new OpenQA.Selenium.Chrome.ChromeDriver(options))
{
chrome.Url = url;
var printToPdfOpts = new Dictionary<string, object>();
var resultDict = (Dictionary<string, object>)
chrome.ExecuteChromeCommandWithResult(
"Page.printToPDF", printToPdfOpts);
dynamic result = new DDict(resultDict);
string data = result.data;
var pdfFile = Convert.FromBase64String(data);
System.IO.File.WriteAllBytes(pdfPath, pdfFile);
}
}
The DDict above is the GracefulDynamicDictionary from another of my answers.
https://www.nuget.org/packages/GracefulDynamicDictionary/
https://github.com/b9chris/GracefulDynamicDictionary
https://stackoverflow.com/a/24192518/176877
Ideally this would be async, since all the calls to Selenium are actually network commands, and writing that file could take a lot of Disk IO. The data returned from Chrome is actually a Stream as well. However Selenium's conventionally used library does not use async at all unfortunately, so it would take upgrading that library or identifying a solid async Selenium library for .Net to really do this right.
Any approach here that uses Chrome on a server, including Selenium, is going to have to deal with Chrome auto-updating, and the Selenium drivers needing to be updated as well as part of your build. Rarely updated code without a strategy to cope with this will break every ~3 months.
https://github.com/puppeteer/puppeteer/blob/master/lib/Page.js#L1007
https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-printToPDF
**The Page.pdf
chrome Dev API command is also deprecated, so if that contingent gets their way, neither the command line nor the Dev API will work. That said it looks like those lobbying to wreck it gave up 2 years ago.
Upvotes: 20
Reputation: 3797
This worked for me in windows
start chrome --headless --disable-gpu --print-to-pdf=C:\Users\username\pdfs\chrome.pdf --no-margins https://www.google.com
Upvotes: 2
Reputation: 877
I was missing "=" after print-to-pdf command.
The correct command is:
chrome --headless --disable-gpu --print-to-pdf="C:/temp/name.pdf" https://www.google.com/
Now it is working.
Upvotes: 2
Reputation: 1229
Do not forget to open your terminal/cmd with admin rights :) Otherwise it will just not save the file at all.
Upvotes: 1
Reputation: 3101
extending the brilliantly simple answer by suraj, I created a small function that is in my sourced path so it works like a CLI tool:
function webtopdf(){
chromium-browser --headless --disable-gpu --print-to-pdf=$2 $1
}
so a quick
webtopdf https://goo.com/some-article some-article.pdf
does the job for me now
Upvotes: 1
Reputation: 103
This is working:
chrome --headless --disable-gpu --print-to-pdf=file1.pdf https://www.google.co.in/
creates file in the folder: C:\Program Files (x86)\Google\Chrome\Application\61.0.3163.100
.
Upvotes: 8