What I’m Working on Now

I just wanted to share what I’m working on now, as Founding Members are probably wondering.

I’m changing how Print My Blog loads posts into the print-page, and how the print-page’s contents are converted into PDF.

How Print My Blog Creates the Print-Page

The “print-page” is the print-ready page generated by Print My Blog. Other plugins that make PDFs usually create the PDF on the server, then let the user download it. Print My Blog, on the other hand, just generates a regular HTML page which your browser can then turn into a PDF, or eBook, or print directly.

Other plugins can’t support creating PDFs with more than a few hundred posts because servers often “time out” once a job takes too long loading all those posts at once. So I needed a way to break the job up into manageable chunks.

So, Print My Blog instead sends the user to the print-page which initially has no post content in it; but it incrementally loads the content in small batches from the server. It does this using WordPress’ REST API.

The REST API is a feature of nearly all WordPress sites, and so it saved me a bunch of time in development. However, after over a year of it, I’m seeing a few drawbacks to it.

The first problem is that many security plugins have disabled it, which means plugin users and myself often need to spend quite a bit of time debugging it.

The other problem is that it’s difficult getting it to generate a PDF with multiple post types, which is a commonly-requested feature for Print My Blog Pro.

Avoiding Generating PDFs in the Browser

Unlike other plugins, Print My Blog lets the user’s web browser create PDF documents. Some major advantages of this are:

• PDFs can be thousands of posts long (whereas trying to make a PDF that long server-side is often too much for the server)
• the browser gets to first execute the page’s Javascript, which is often critical for making the printout look right
• there’s a lot less code needed in Print My Blog, which saved me time and makes the download much smaller

But there have also been some disadvantages:

• Some browsers, like Firefox, need an extension to create PDFs
• Different browsers generate PDFs differently; for example, Firefox’s PDFs don’t contain hyperlinks but Google Chrome’s do
• Browsers only do a mediocre job of laying out the content so it looks right in a printed page; for example, sometimes images are cut in half

It seems the best option is to use the software Prince XML, or the DocRaptor webservice, to generate the PDFs on a separate server. These options aren’t free, but they should address the problems browsers have.

• The user won’t need to install any browser extension
• PDfs will look the same regardless of which browser is being used
• They have the best support I’ve seen for print CSS

What’s Next?

My development style is to try to build something simple and bare-bones first, that works from end-to-end, then circle back and improve everything along the way. It’s an iterative approach inspired by The Lean Startup and Shape Up.

So once I have something working from end-to-end, we can start discussing what to improve on.