2 ms·

> There are some good server-side tools for this (QPDF, PDFTk, PDFBox, iText, Hummus) Fake news! QPDF[0] can work offline on local PC - just download AppImage

> There are some good server-side tools for this (QPDF, PDFTk, PDFBox, iText, Hummus) Fake news! QPDF[0] can work offline on local PC - just download AppImage and execute it on your Linux desktop! > but for better speed and privacy I really wanted a 100% client-side solution. Think, you mean "offline solution", because "client-side solution" is always mean that is part of some "online service". [0] https://github.com/qpdf/qpdf/releases https://github.com/qpdf/qpdf/releases

dschnelldavis 9y ago
Nope, I definitely meant "client-side solution". I wrote this library to work as part of an online service to help lawyers assemble Exhibits (www.magicexhibits.com). The first version of that site uploaded everything to a server, where I used QPDF and Hummus to put everything together into a big .pdf, then downloaded the result. It worked, but it was slow. The second version used an Emscripten encoded version of qpdf[0] to move part of the processing client-side (meaning into the browser), which made the processing faster. But even after compressing as much as possible, the Emscripten qpdf.js was 4mb, which made the site load time much slower. So, finally, I wrote PDF Assembler, which loads fast and does almost all of what I need. If someone loads a document I can't process with JavaScript alone, like a .docx file, I still have to send that to a server to convert to a .pdf. But PDF Assembler does the majority of the processing right in the browser, which makes the site a LOT faster. And, as a nice side effect, our users like the improved privacy protection, because as long as all their input files are .pdfs, those files never leave their computer. Personally, I use QPDF on the command line (in OS X) quite a bit, and I've also used PDFTk and Hummus on my local computer. But our users aren't as computer savvy, so it was important to make a solution for them that was as simple as possible - meaning one that didn't involve downloading and installing any software. So an SPA is an ideal solution for them, and an SPA that uploads as little as possible to the server is even better. [0] https://github.com/jrmuizel/qpdf.js https://github.com/jrmuizel/qpdf.js

dschnelldavis 9y ago

Nope, I definitely meant "client-side solution". I wrote this library to work as part of an online service to help lawyers assemble Exhibits (www.magicexhibits.com). The first version of that site uploaded everything to a server, where I used QPDF and Hummus to put everything together into a big .pdf, then downloaded the result. It worked, but it was slow. The second version used an Emscripten encoded version of qpdf[0] to move part of the processing client-side (meaning into the browser), which made the processing faster. But even after compressing as much as possible, the Emscripten qpdf.js was 4mb, which made the site load time much slower. So, finally, I wrote PDF Assembler, which loads fast and does almost all of what I need. If someone loads a document I can't process with JavaScript alone, like a .docx file, I still have to send that to a server to convert to a .pdf. But PDF Assembler does the majority of the processing right in the browser, which makes the site a LOT faster. And, as a nice side effect, our users like the improved privacy protection, because as long as all their input files are .pdfs, those files never leave their computer. Personally, I use QPDF on the command line (in OS X) quite a bit, and I've also used PDFTk and Hummus on my local computer. But our users aren't as computer savvy, so it was important to make a solution for them that was as simple as possible - meaning one that didn't involve downloading and installing any software. So an SPA is an ideal solution for them, and an SPA that uploads as little as possible to the server is even better. [0] https://github.com/jrmuizel/qpdf.js https://github.com/jrmuizel/qpdf.js