Phantom and Chrome

[eljefe6a]

The PhantomJS maintainer is stepping down because Chrome and Firefox are going to support headless browsers now. Do you have any thoughts on Decktape given this news? Will Decktape start using Chrome or does headless mean you can execute a bash script to output a PDF?

I'm more starting this as thread for discussion.

[eljefe6a]

I've taken a look at Chrome's headless API and it looks like we'll still need a Decktape of some kind to script and output the slides correctly.

One of the reasons I moved from manual Chrome printing to Decktape is because Remark doesn't size the PDF output correctly. The slide only occupies a smaller portion of the document in comparison to the rest of the page. You have to mess around with the window sizing.

[eljefe6a]

This is the method that will print out a PDF. My guess is that Remark slides would need a sleep for some time, run printToPDF with the appropriate properties, and save out the Base64 encoded PDF to a file.

[astefanutti]

Thanks for starting the discussion. They are multiple points here that I would articulate under the two following parts:

Web browser drivers support

Ideally, DeckTape would work across the various Web browser drivers available out there. We've already tried that approach with SlimerJS in #7. Generally, they tend to implement / support the PhantomJS API and it seems that's a direction the Chrome dev team would be willing to take.

That being said, all these drivers PDF rendering API is implemented by delegating to the browser PDF printer (that an actually end user would access through the Print page menu item) which tends to lead to poor results for HTML presentations.

Hence the DeckTape value proposition to add a new PDF Printer API (astefanutti/phantomjs@f0259c95942a24163eb16ef19887cc313525573d) and slide navigation engine (https://github.com/astefanutti/decktape/blob/41861c135a3a9c0af1d06d370ba25f56e4811aec/decktape.js#L288) to output the expected result.

It's quite straightforward to implement such an API in PhantomJS as it leverages low level APIs from Qt. However, my current understanding is that it requires a lot more work for other browser drivers. That being said I'd be glad to be proved wrong 😉. Anyway, that leads to the question of the PhantomJS / WebKit version...

PhantomJS project

The problem with the current PhantomJS version that's used by DeckTape is that it relies on QtWebKit that's been deprecated and that depends on an old WebKit version. That means most recent CSS3 features are not supported for example. Hence the question of the PhantomJS development activity, that I'd split in two points:

• While the PhantomJS core maintainer has posted an announcement that he's step down, it is not really an issue for DeckTape as the primary concern resides at the level of QtWebKit
• A new port of QtWebKit is actively being developed at https://github.com/annulen/webkit. I haven't tested it yet though that looks very promising. My current plan is to wait a little until the beta stabilise and I'll start upgrading DeckTape to this new QtWebKit version.

In case the later point turns to be conclusive, it somehow lowers the importance of the multiple Web browser drivers support.

[astefanutti]

It seems Puppeteer could be used to leverage headless Chrome. Let's track that effort in #100 and close this one.