You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just thought it would be a really common thing for someone to be skimming through the readme to find how much data they could store on one sheet of paper in order to judge if they would like to use paperback or not. Statements like "as most users won't need more than 50 sheets" aren't nearly as helpful as for example, "you can store ~12kb of data on one sheet."
The text was updated successfully, but these errors were encountered:
For reference, at the moment one sheet contains 9 QR codes, each storing ~1kB so it's ~8-9kB per sheet at the moment (with the caveat that I haven't gotten around to writing code to generate multi-page PDFs yet).
In theory, you can store up to ~4kB in a single QR code, but in my testing the surface area we use for each QR code is not large enough for a 4kB QR code to work reliably (not to mention that the QR code might get damaged over time). I suspect 2kB is the most we can reasonably do, so ~18kB per page at most.
We also don't compress the data at the moment. With compression you can probably store even larger plain-text documents.
Just thought it would be a really common thing for someone to be skimming through the readme to find how much data they could store on one sheet of paper in order to judge if they would like to use paperback or not. Statements like "as most users won't need more than 50 sheets" aren't nearly as helpful as for example, "you can store ~12kb of data on one sheet."
The text was updated successfully, but these errors were encountered: