qpdf VS Paperless

QPDF is a CLI tool that performs content-preserving transformations on PDF files. We have another tool for managing files!

Given how well Preview.app and Safari work for viewing >99% of PDFs I actually encounter in the wild, this article makes Apple's engineering decisions look good.

It also confirms many suspicions I've had over the years that have led me to, e.g., running all PDFs from questionable sources through VirusTotal before viewing on platforms where I wouldn't normally run antivirus software.

The original article also confirms my suspicions that this step is inadequate:

Because the Launch action can be considered as a danger- ous feature, we conducted a large-scale evaluation of 294,586 PDF documents downloaded from the Internet, in order to research if there are any legitimate use cases at all. Of those documents, only 532 files (0.18%) contained a Launch action. While none of the files was classified as malicious according to the VirusTotal database, we conclude that the Launch action is rarely used in the wild and its support should be removed by PDF implementations as well as the standard.

Incidentally, the Launch action is still present in the most recent version of the PDF standard[1], with only OS-specific launch parameters deprecated (which include passing arguments to the launched executable, so eliminating the deprecated feature is still a significant security gain).

Finally, I'm both personally and professionally curious about how the non-DoS examples in this articles may apply to non-viewer PDF tools and libraries like qpdf[2] and Ghostscript's original and recently reimplemented PDF interpreters[3].

[1] https://pdfa.org/resource/iso-32000-pdf/

(registration required, but at least the base standard is available at no cost; sadly, important incorporated standards like ISO 21757-1:2020 [ECMAScript for PDF] are not)

[2] https://qpdf.sourceforge.io

[3] https://ghostscript.com/blog/pdfi.html

I know you're talking about GUI editing, but I've found libqpdf[1] incredibly useful for making programmatic PDF edits with minimal (typically no) structural disturbance.

[1] https://qpdf.sourceforge.io

Solved this. So the string which we were concerned about depends on the time, which is why it changes everytime a new document is generated with the same source PDF. it is a meaningless string really. from the documentation, it gives this explanatin. To be sure, i raised an issue with the guys at QPDF and they were quick to answer the question too. The explanation theyve given is even more clearer.

Hi, this is my first Emacs package! It provides a transient wrapper for the qpdf command-line tool aimed especially at users of pdf-tools or at least DocView. With it one can, for example, remove/reorder/split/rotate pages of a pdf file, merge pdf files, remove annotations, and apply a range of transformations to a pdf file. See the qpdf documentation.

There are some here, as test files in the qpdf library: https://github.com/qpdf/qpdf/tree/main/qpdf/qtest/qpdf

(I wrote a low-level PDF parser and ran it over the PDF files that happened to be present on my laptop—just regular ones—and ran into some files that (some) PDF viewers open but even qpdf doesn't. I say "even" because qpdf is really good IMO.)

If you're comfortable handling the (typo)graphical aspects of the PDF yourself and have the ability to consume a C++ library, I've had good experiences using the Apache-licensed qpdf[1] library to handle the low-level structural aspects of the PDF standard. It's particularly convenient when your application requires structure-preserving integration of existing PDF content.

Simple example applications, each completed in 2–3 days, both in C#, using C++/CLI to integrate libqpdf:

1. Overlaying fixed-format text on pre-existing blank PDF form pages, ensuring the content of each distinct form page is embedded exactly once, and that all necessary assets (fonts, images, etc.) from the blank form PDF pages are included in the output PDF.

2. Losslessly combining a sequence of PDF, TIFF, and JPEG images into a single PDF with bookmarks pointing to the first page of each source file and existing image compression maintained where possible. In this application, only the source TIFFs were anything other than arbitrary (i.e., the TIFFs were more-or-less baseline images coming from a small number of scanning systems, but the JPEGs and PDFs came from all sorts of different applications).

[1] https://github.com/qpdf/qpdf

Use qpdf https://github.com/qpdf/qpdf

I was looking for a way on macOS to batch remove the user password from a bunch of PDF files that had the same password. I found the easiest way was to use qpdf with the following command:

Paperless-ngx is the successor to the original Paperless & Paperless-ng projects, both of which are now in public archive. The original projects are not dead, but rather, continued through the open source community!

There's this:

https://github.com/the-paperless-project/paperless/issues/20

I don't know if it made it's way into this fork.

Paperless: https://github.com/the-paperless-project/paperless

Agreed. It's difficult to beat paperless* for single-user systems. It does have some rudimentary user management from Django, but it's an admin party and there's no way to give users separate repositories. They've been looking into it for years, going back as far as the original paperless project. I imagine such a feature is difficult to add on as an afterthought because it touches everything, so it should be built in from the very beginning. And it seems they're looking for a perfect implementation, which may or may not exist. Thus, years later, paperless* remains effectively a single-user app.

If I understand this correctly, the original Paperless was archived (Archival notice)[https://github.com/the-paperless-project/paperless/commit/9b...], so Paperless-NG was created.

Now that Paperless-NG seems to be going unmaintained (last commit on 15th Sep 2021), Paperless-NGX has been created with a focus on an org, so that the continuity of the project can be maintained with a simple path for the original creators to join back if they want to.

I don't think the community could have handled this better!

As many of you know "Paperless-ng" was a very popular fork of the document management system "Paperless". The initial author of -ng, Jonas Winkler, created an amazing project that was eventually designated as the 'official' successor. He maintained a furious development pace for some time but as of this post hasn't been heard from in months. A group of folks dedicated to the software (myself included) decided to try and revive the project and hopefully set it up for a long future. Yes, a similar thing happened with the original Paperless, we are hoping to avoid some of the same mistakes. See jonaswinkler/paperless-ng#1599, jonaswinkler/paperless-ng#1632 and historically the-paperless-project/paperless#711 if you are curious for more about all of this.

yes, I know that project. Paperless-ng is actually a fork of paperless project. I borrowed many great ideas from both projects. Unfortunately both projects are now archived (paperless-ng is not officially archived, but in last 6 months there was no development, as it looks to me that main developer lost interest in the project).

I have a Brother ADS-1700W, works fine, a little fiddly to set up the profiles for one touch scanning but once it's done it's fine. I set up a workflow with https://github.com/the-paperless-project/paperless that lets me scan straight into OCR. https://github.com/jonaswinkler/paperless-ng is the fork that I'm going to upgrade to in my CFT.