You can generate pdfs with headless Chromium/Chrome pretty easily[1].

    chromium-browser --headless --disable-gpu --print-to-pdf=output_file_name.pdf file:///path/to/your/html

[1] https://developers.google.com/web/updates/2017/04/headless-c...

Any idea when exactly the PDF capture is performed? So many pages now render a minimal initial load, while the actual content is greatly delayed (usually < 100ms, but sometimes 3+ seconds) due to being loaded from one or more AJAX sources.

Capturing the PDF at even the onload event (let alone the useless DOMContentLoaded event) is going to capture an incomplete picture in a huge number of situations. Frankly, a PDF capture at onload event is going to be utterly unusable. Is there a way to set a delay before capturing, ie: 10 seconds?

In an ideal world, a true "finished loading" event would trigger only after all DOMContentLoaded and onload handlers are executed, only once any AJAX requests launched by such handlers are completed (including requests fired off in their handlers, recursively). Of course, websockets and long polling ajax would still interfere with detecting a true "finished" event, but it'd be better than setting an artificially large delay of 10+ seconds.

Amusingly, I had this same problem back in ~1999 when trying to automatically screen capture webpages with Netscape on X.

Except then it was just a case of "wait 30 seconds and pray" because there was none of this fanciness.

(bloody kids, get off my lawn, banging two rocks together, etc.)

I don't think this feature is "utterly unusable". You can run your JS, wait for whatever events you want, and then pipe the resulting HTML to a --print-to-pdf command.

The primary reason to print a pdf would be to do so to any random 3rd party page. Sadly, you have no control over how 3rd party sites render/load their content. And --print-to-pdf likely captures the render of the page at some predetermined point, my guess being the "onload" event. Which, again, is not going to result in a fully rendered page for many sites that load in their primary content using AJAX.

That's a good question but I don't know the answer. The reports we generate don't use js so I've never needed to investigate.

Wow - thanks for posting that: could come in handy on the project I'm currently working on!

We're using Chrome Headless inside Docker to produce thousands of PDF reports from an Angular/D3 web app.

It works very well, but there are some gotchas with regard to the Chrome Remoting Interface.

Can you elaborate on some of the issues you're having in the Chrome Remote Interface?

Yeah, D3 is what we're working with as well; also need to be able to embed the charts in Powerpoint, but that'll be a different story. All fun and games.

You can use inkscape’s CLI interface to get SVG from pdf, and then manipulate that with any XML editing library automatically

Is this open source? It would be very interesting to take a look at!

If only browsers supported creation of page headers and footers.

@page { @top-center { content: element(pageHeader); } } #pageHeader{ position: running(pageHeader); }

http://www.w3.org/TR/css3-gcpm/#running-elements

Thank you for this. I've been doing this so wrong for a long time.

True - but you can get them to output to PDF, then composite/stamp this pdf onto a PDF with headers/footers/whatever on it. This is very easy to do with pdftk.

I built a simple REST API that wraps this call for my other projects and it's been working great the past few months. If this would be useful to you my contact info is in my profile.

Remember that if you pass through any data from an outside source, you're running their code on your browser when you thought you were just printing a document.

The security issues don't apply in all circumstances, of course, but if you feel like taking a shortcut to PDF generation and printing through a headless browser, you need to keep them in mind.

I highly recommend that anyone using a headless browser that may access outside sources employ something like this to run the headless browser in an external environment, in this case AWS Lambda: https://github.com/justengland/phantom-lambda-template

I used this approach for a project at a previous company and not only did it keep the potentially unsafe external code execution isolated from the rest of the stack, but it also proved to be fantastically scalable because of the ability to have AWS Lambda running many headless browsers in parallel compared to trying to scale something like this out on your own hardware.

That's a neat approach, I'm not on anything like that scale though, looking for something to get rid of JasperReports.

Did you find any library that implements this? I mean, it should not be hard to implement, just slap together some templating language like thymeleaf or velocity and shell it to the headless browser. But still, it would be nice to have all this already implemented.

Last time I had to generate PDF's from scratch rather than inheriting a mess I built a custom heavily modified version of bootstrap (really ripped it apart) just for print use and fed it to wkhtmltopdf via snappy, it worked great and was very fast to develop since I could output to the browser as HTML to debug.

Rendering a PDF you got some other way is also "Running their code", just in a different sandbox :-)

I don't think you're thinking of the same case: this is "open a browser, and output a PDF"; not "read a PDF."

If you need professional typesetting from HTML+CSS, Prince XML is still king, I'm pretty sure. It can be invoked & run heedlessly.

It also supports page-oriented CSS declarations and variables, like headers, footers, page numbers, etc.

What are the features that make Prince XML better than headless chrome? Prince XML is not open source or cheap.

Simply put, it's designed to make PDF output and provides a lot of quality-of-life tooling around that. Better support for CSS paged media and non-HTML XML input, better handling of page-spanning tables, shims for things missing from paged media (like hyphenation and ligature controls, PDF-specific objects to modify output with Javascript, Javascript embeds into PDF output), better out-of-the-box styles, better documentation and support, and more predictable output and better debugging tools.

Browsers are catching up on paged media options, but they're not all the way there yet. The rest of the stuff Prince does is not (and arguably shouldn't be) in the scope of headless Chrome.

There was a brief moment where headless Chrome supported flexbox in print before Prince did, but that was fixed a month or so ago in Prince dev and should land in production soon if it hasn't already.

PrinceXML is in a league of it's own. Very, very light weight. Very fast and it has outstanding output. The price tag is steep for sure, but if your business relies on PDF output then nothing comes close.

Do you use it in the context of technical documentation? Does it make using Docbook a bearable experience?

It has unmatched print CSS support, so it'll take anything you throw at it.

Also it blisteringly fast. You'll process 10 documents before headless Chrome has even finished starting up.

There's a free trial which prints a watermark so you can give it a spin. very easy to get up and running, even has a GUI so that you can throw some test docs at it without any effort at all.

You should check out their samples: http://www.princexml.com/samples/

Stuff looks like it was created with QuarkXPress or Adobe InDesign.

It just hit me why people continue to ask for headless browsers to be able to print to PDF -- for reports!

To get better control of the print job, do you ever use Adobe InDesign?

One word -- wkhtmltopdf

I've used wkhtmltopdf for years and it's really great. However, having a browser (headless Chrome and now Firefox) render the page closes the gap between what we build in HTML and what we want to output in a PDF, without having to deal with nuances of the wkhtmltopdf rendering engine.