pdf stapler / stitcher

[mrgum]

Thanks for the ingredient.

The stapler is currently using Apache PDFBox, there are loads of tools out there for doing that, for example I use qpdf

I'm wondering how best to allow multiple implementations, could be a single script with a config value but might be cleaner and easier to extend / allow users to do their own thing to rename bin/stitchPDFs to bin/stitchPDFs-Apache-PDFBox and symlink it to bin/stitchPDFs

That way I can add bin/stitchPDFs-qpdf and choose to use it.

Happy to implement the change and take a stab at updating the docs but thought I'd get any comments first

[mrgum]

p.s. pdfbox is running with java -Xmx1G I'm hoping it never needs a whole 1G but another good reason to replace the stitcher

[drn05r]

I will look into other options/ However, PDFBox has been used reliably with numerous EPrints repositories for a number of years and is well supported and still actively developed. Often up to 1G is needed when coversheets large PDF documents such as PhD theses, especially if they contain multiple high resolution images.

stitchPDFs can be locally modified to reduce memory usage or written to support an alternative tool. If you don't want to modify existing code, you can create you own stitchPDFs script somewhere under the EPrints path (although technically anywhere on the filesystem with suitable permissions) and update $c->{gs_pdf_stitch_cmd} in either z_coversheets.pl or a configuration file that will load later (i.e. alphabetically later) to use this script in preference. The only restriction is that it must only require the following three arguments, which will be provided by EPrints when trying to produce a coversheeted PDF:

1. generated PDF coversheet location
2. input file (i.e. uncoversheeted PDF) location
3. final output file location