Add option to print human-readable information to stdout

[arcanemachine]

This is just a small modification that enables the QR code data to be printed to stdout by using the --human-readable-stdout flag, so that it can, for example, be piped to a text file and printed off.

It's not pretty, but it easily and effectively adds an important layer of redundancy. In case 1 or more QR codes becomes corrupted, the data can still be recovered by manual entry.

The flag itself was chosen so that it doesn't collide with a more well-integrated --human-readable flag that would presumably be added to the document using Pillow.

[za3k]

Got it. I'm going to think about this patch after adding erasure coding, which would allow you to lose QR codes already. Would you still want this feature if you only needed something like 7 out of 10 codes to be scannable?

[za3k]

A few questions in the meantime:

• What are the advantages of this over say, printing the original document?
• Why print to stdout? Why not include it in the PDF?

I would suggest taking a look at the output of https://github.com/intra2net/paperbackup for a more usable version of this idea.

[arcanemachine]

1. I use this program to make backups of password stores, which are themselves encrypted and compressed (thus not really printable). Having a human-readable copy of each code is a form of insurance against the failure of one or more codes to scan. Better to manually enter a few hundred characters than to recopy several thousand characters and hope I didn't make an error.

2. Using Pillow to generates images is incredibly tedious (admittedly my experience with it is not much). By exporting the text to a file, I can open it in a word processor, and print it within a minute. It was basically a labor-saving effort compared to calculating line lengths and margins. In short, "perfect is the enemy of good". I made an implementation that appended to the PDF but I wasn't satisfied with it, so this was an easy compromise that gave me exactly what I needed.

If it doesn't fit with your vision, that is totally fine. It just gives me extra peace of mind against data loss.

The repo you linked also doesn't appear to offer this functionality, as it prints a giant unwieldy blob of text at the end. Smaller codes == less work and less chance of error.

[za3k]

Evaluating this patch I will say no as-is (accepting quick-and-dirty patches is a problematic route). I'm still thinking about whether the feature of human-keyable text is worth including. If a feature is worth including I'm happy to do the extra work to do it "right". Please don't work on this more just yet, because I'm not sure either way.

I'm trying to make sure I understand the motivation for the feature. Would you still want this feature if you only needed something like 7 out of 10 codes to be scannable? Is plain text somehow more "safe" feeling than QR codes?

Re paperbackup, a giant blob of text is mostly true--in that you can't correct a single QR. However, I'll draw your attention to the per-line checksums, which I thought was a nice feature for humans keying in text.

[arcanemachine]

I totally understand if you don't want my quick-and-dirty patch, it was something I whipped up to fulfill a personal need, and I just wanted to put it out there to see if it gained any traction.

With a human-readable copy of backup, I simply feel like I have extra insurance against the scanning software arbitrarily deciding that my QR code is invalid. For example, while I was experimenting with the software to find out if I could attain greater storage density, my toner was also low, leading to a less-than-perfect image that would sometimes scan, and sometimes not. What drove me to create this code was the feeling of a complete lack of control over whether or not the computer recognized the image. Now, I feel like have a truly fault-tolerant backup method (although it admittedly doubles the size of the backup in terms of paper used).

As long as one missing code can corrupt the backup, it doesn't matter how many codes it needs to replace. One is too many. And yes, it definitely provides a feeling of safety, whether or not it is well-warranted. The entire reason I want a paper backup is to avoid the issue of digital corruption.

If all it takes for my backup to be worthless is for one single code to not scan, then I do not think it is a very robust backup solution. Human-readable codes are an escape hatch to deal with that problem with a minimum of hassle (while still preserving the paradigm of a physical, non-digital backup).

Also, the checksum thing is definitely a nice touch. I might copy that idea.

[za3k]

https://github.com/za3k/qr-backup/issues/12 covers this reasonably well. I'll add a note to make data human-keyable.

[za3k]

Thinking about it more, I think the correct solution is to add a text-backup to complement qr-backup. I've opened an issue to create a second CLI tool specifically for this. I think this is the easiest and cleanest solution. Message me if you'd like to work on it!

[arcanemachine]

Sorry, I'm afraid I don't have the time to pursue this at the moment. I use the solution in this pull request to make a readout of the data which I then copy to a word processor and print. It's not the most elegant solution in the world, but it works for me.

If you are willing to merge this pull request, we will at least be in the position of having a working solution to offer while an improved solution is in the works.

[za3k]

On 2022-04-08 8:03 pm, arcanemachine wrote:

Sorry, I'm afraid I don't have the time to pursue this at the moment. I use the solution in this pull request to make a readout of the data which I then copy to a word processor and print. It's not the most elegant solution in the world, but it works for me.

Totally fine! It'll still get added eventually, I think it's a good idea. Just thought you might be interested if you wanted to call dibs.