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.