Support for multi-page PDFs

[adamkaplan]

I know this was an intentional design decision, but was it a hard decision or just for the minimum viable product?

At some point, especially for smaller images, the PDF headers and disk page size become the limiting factors for compacting data. I'm also considering encryption– it might be more efficient to use the PDFs encryption on a single document rather than encrypting a tar ball of a few dozen tiny PDFs.

Have any thoughts on this? I'll probably take a shot at it.

[tparry]

I deliberately designed the API to work with just the first page. The reason is I didn't want people to use it as an easy-to-use full PDF rendering library (it's made for small vectors after all).

Although, I didn't consider the PDF headers making up the bulk of the file, and yes you are correct that putting multiple pages in the same file is an effective way to reduce the overall file size.

I just ran a test of a single vector in a PDF which after my PDFShaver tool came to 4,228 bytes.
Putting a bunch of vectors across 6 pages in the same PDF file it came to 12,461 bytes, about half the size if they were individual files.

As for encrypting, I didn't think many would want to encrypt their images (it seems like a feature more appropriate for real documents) but I suppose it could be a requirement from some developers.

Edit: I saw your pull request too, tonight I'll have a look and also consider an API plan for moving forward with multiple pages and encryption :)

[adamkaplan]

I should not have mentioned encryption in this issue. I'm only thinking about it. Definitely not something I need to tackle for quite a while. Let's just stick to the multi-page pull request for the time being.

Thanks for responding!