qpdf VS markdown-preview-enhanced

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:

I tried out Dendron a few months ago for personal note-taking, technical docs, and organizing tasks. I was excited at first, but overall the cons outweighed the pros for me.

Pros/exciting things:

1) There's a simplicity in using VS Code for writing notes and docs if (and probably only if) you already spend your day in VS Code, like I do.

2) The Markdown Preview Enhanced VS Code extension (which is a dependency of Dendron) is super cool for having so many "batteries" included. For example, check out all the diagram types it supports: https://shd101wyy.github.io/markdown-preview-enhanced/#/diag... . I still use it, separately from Dendron.

3) Storing my data as plain text on disk (backed up by GitHub or Dropbox) has nice properties compared to how SaaS apps do it (e.g. if you use Notion, say, your data materializes out of "the cloud" when you launch the app, and otherwise has no tangible existence). When my data is plain text on my local disk, I own it; I know I can export it, I can run whatever editor or program on it; I can access past versions (via git or Dropbox); I don't have to worry about it being corrupted, or accidentally deleting some of it, or not being able to access it because of server issues, or not being able to export it, or being offline, and so on.

4) The Dendron docs ("wiki") site is created using Dendron. It's a cool thought that I could create a nice website of documentation or notes without leaving VS Code.

Cons:

1) Can't access my notes from mobile.

2) Major warts in navigating between notes. Each note has a tab for editing it and a tab for viewing/previewing it. Opening a note behaves differently depending on which tab is focused. Clicking links to go from one note to another doesn't work very well.

3) Poor full-text search (just VS Code's code search).

4) You can't specify an order for notes, only unordered hierarchy, and you can't easily view multiple notes at once, which means keeping lots of short notes, or using different notes for different sections of a document, doesn't really work. There's a tension in any note-taking tool between short notes and long notes. Should notes be as short as possible? Or stretch into long documents? The ideal tool IMO would blur the difference between an ordered hierarchy of sections within a document and an ordered hierarchy of notes within some grouping. Dendron makes it seem like it is for keeping thousands of small notes, but the ways in which you can view, organize, and navigate between notes (lack of good "browse," search, links, lists, seeing multiple notes, next/previous note, and so on) are so limited that it makes more sense to write long documents. In which case, all you really need is Markdown Preview Enhanced and the file system.

My favorite implementation is Markdown Preview Enhanced, to be exact, @shd101wyy/mume, but I want a little more features...

VSCode or Atom IDE with Markdown Preview Enhanced

Editor preview: Yes

And one of the best tools to create PDF is Visual Studio Code, if you know how to use Markdown Preview Enhanced properly. (I've just noticed that I can use this in Atom as well.)