[nearbygoogler]

1. Print the source code in a micro-barcode in a physical appendix.

2. Make the first exercise in all books be to code a simple barcode image interpreter. And just include the walkthrough and source as typed text.

You should be able to get a few MB on a page easily. Future proof as long as there are cameras on phones.

[ivegotnoaccount]

> You should be able to get a few MB on a page easily

A few hundred Kb, maybe, but a few MB seem unlikely. If I take the best case scenario (no optical aberration, perfect sensor...), my phone has a 48MP camera. We cannot have 48M * 3 colors as those 48MP are after Bayer matrix handling. We also cannot have more than one bit of information per pixel, due to printing often not having "real" greyscale but some kind of dithering and you don't know for sure how it would interact with your sensor. So in the best case, 6MB. But then, you need to add error correction: books prints are not perfect, especially at a sub-0.1mm scale. They are also not perfectly planar as paper is grainy. And the camera is not exactly at a 0 angle... In the 3 axis. So you would need to have the printed pixels be way larger than the sensor ones to be able to offset this. And so on.

[remram]

I think you confused printed pixels with camera pixels along the way.

[ivegotnoaccount]

I explicitly talked about the best case scenario, which would have been "one camera pixel is able to retrieve precisely the information of one printed pixel (or several printed pixels that act as one)"

From there, I simply listed sources of error that would make it worse and words. The only place I could see conflation occurring is when I wrote about "sub 0.1mm" which indeed refers to the printed thing, and correspond roughly to the tolerance that would be needed to achieve millions of "printable" pixels, but even if it's about the printed pixels, it still limits the amount of information that would be stored.

Would you mind indicating where there seem to be confusion according to you? Re-reading it quickly, the comment seems consistent and indicates that both the camera pixels AND the printed pixels would cause issue.

[nearbygoogler]

I don’t know, still seems feasible. High quality full page images can be printed at ~2500x3500 pixels per page [1] (random print shop from the internet, but representative AFAICS), and that’s just what printers recommend for human readable images, they can produce images easily to 1200 DPI.

In another example, take the Machine Identification Codes (MIC) tracing dots that basic home printers can produce [2], (I bet the publishing industry could do much better to produce a high density grid.)

These dots have a stated diameter of 0.1 mm, and on an 8”x10” area one could get a grid of 80x25.4x25.4x(1/0.1mm)x(1/0.1mm)= ~5.1M dots.(wikipedia claims larger spacing, but that must be the protocol, printing itself allows for highly precise positioning) And that’s just for one color. Use CMYK (you could imagine a sub-project to design a 8bit color based dot scheme) and compression, and even with ECC losses I can see a few MB of encoded source per page being possible. And writing that decoder would be a great exercise!

[1]: https://www.docucopies.com/image-resolution/

[2]: https://en.m.wikipedia.org/wiki/Machine_Identification_Code

[remram]

The dithering in the page pixels don't limit the amount of information you can get through your camera pixels.