PaperBack: How to store arbitrary data on A4 sheets of paper (2007)

this seems like one of the most efficient ways to store&#x2F;print read-only data on paper, perhaps data can be compressed with wrt+paq8px so compressed (text) data can potentially be doubled to a total of 12*500 KB of books; 6 MB text on one A4, so the KJV bible could fit. <a href="https:&#x2F;&#x2F;www.mattmahoney.net&#x2F;dc&#x2F;text.html#1250" rel="nofollow">https:&#x2F;&#x2F;www.mattmahoney.net&#x2F;dc&#x2F;text.html#1250</a><p>or... a few high res photographs of important moments or persons. A VR environment or 45 minutes of speech or music @1.5 kbps with Vocos or Meta&#x27;s EnCodec <a href="https:&#x2F;&#x2F;gemelo-ai.github.io&#x2F;vocos&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gemelo-ai.github.io&#x2F;vocos&#x2F;</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;Rupan&#x2F;paperbak">https:&#x2F;&#x2F;github.com&#x2F;Rupan&#x2F;paperbak</a><p>Perhaps make it an android, linux or ios app... even though running an old windows binary on android is feasible.<p>Or perhaps one should just use paper to fit a maximum of 75 KB of squashed readable multicolumn (6) on a landscape A4 printed with Tahoma smallest print. Perhaps use an alphabetic shorthand like bref, yash or briefhand for a human readable 30% compression. Who needs more then 100 KB on an A4 anyway? One and a half month of journaling. Would be nice if I could get one year of human readable personal insights&#x2F;interactions&#x2F;things completed on a double-sided A4 without advanced compression.

It says in the top &quot;presents his new open source joke&quot;, but I actually think this sounds genuinely useful. So many other media formats become unsupported by modern operating systems. Cloud services get shut down left and right. Tapes and floppies and spinning rust gets demagnetized. Optical media has a lifespan too. We have paper from hundreds of years ago that is in decent condition.

I was curious how this would compare to QR codes:<p>TFA suggests that consumer scanners and printers can successfully work at a minimum of 200DPI. A QR code can store almost 3kB in a 177x177 matrix, which allowing for some padding nicely fits in a square-inch @200DPI.<p>This would allow approximately 285485 bytes per page before compression. For better error-correction, you could up the ECC in qr codes, or you could apply reed-solomon to the data before encoding. The latter has the advantage of correcting errors that take out most of a single QR code.

Someone should reimplement this for use with cheap laser engraving machines so we can make physical backups on any material like stone, wood, stainless steel, or plastic.

And not a single photo of a resulting printed page. Why do developers absolutely loathe showcasing their final product?

Natural history collections may still be interested in such. They merge the concept of needing small footprint size labels (e.g. 4 point Times) that go under the physical specimen. The label must not take a lot of space, so for 2mm long insects you have maybe 4-5 lines of ~30 characters. We&#x27;ve long used QR or 128 codes to encode a small barcode of the catalog number for that specimen. The hotness now is the &quot;digital twin&quot; or &quot;digital exentended specimen&quot; for these physical specimens. Perhaps encoding cheaply some key attributes on another label would let the physical part of the twin track the evolution of the digital twin. The key here is that these collection&#x27;s goal is protection of the specimen over time, we&#x27;ve been doing it since Linneaus (over 250 years), so archival considerations (acid free paper and ink), and persistence of data beyond the initial layer are important.

&gt;You may ask - why? Why, for heaven&#x27;s sake, do I need to make paper backups, if there are so many alternative possibilities like CD-R&#x27;s, DVD±R&#x27;s, memory sticks, flash cards, hard disks, streamer tapes, ZIP drives, network storages, magnetooptical cartridges, and even 8-inch double-sided floppy disks formatted for DEC PDP-11?<p>Ah, the good old days! It is amazing what we have at our disposal now for very little money. I really do like the concept behind this however. It catches you off guard because you do think, just as they wrote, &quot;why in the world would I use paper for a backup in 2024?&quot; ... then they explain it in one sentence and it makes obvious common sense.

Supposedly Github Arctic vault was stored in giant 2d barcodes on film reels <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Boxing_barcode" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Boxing_barcode</a>

I am reminded of a chat I had with the founder of <a href="https:&#x2F;&#x2F;www.clump.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.clump.org&#x2F;</a> , trying to do paper backups as a service.

I back up my private SSH keys by printing them as QR codes.

Earlier discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10245836">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10245836</a>

&quot;Grid should be more or less parallel to the sides of the scanner (maximal angle must not exceed ±7°), but general orientation is unimportant: portrait, landscape, upside down or even, if you use transparencies, flipped. Orientation may change from one paper sheet to another.&quot;<p>Transparencies. So technically not just paper!

Same name, same idea, better-looking implementation: <a href="https:&#x2F;&#x2F;github.com&#x2F;cyphar&#x2F;paperback">https:&#x2F;&#x2F;github.com&#x2F;cyphar&#x2F;paperback</a>

Before I clicked I assumed it was just going to be a pencil.