Open za3k opened 3 years ago
Alternatively, you could directly allow making multiple QR codes from one buffer of data.
Just a random person, but I am on the fence about this one. Maximum number of bytes, definitely. However, there are many approaches to breaking data up, and are several applications which already do this, and many take a different approach. I, personally, am considering using 7z's multi-archive feature, and need to explore it in more detail.
Number of bytes per rectangle would be the metric I am most interested in. I find that at least handheld scanning applications have a hard time with the larger codes. Unfortunately, I am sure it is not that easy to calculate that metric.
Number of bytes per rectangle would be the metric I am most interested in. I find that at least handheld scanning applications have a hard time with the larger codes. Unfortunately, I am sure it is not that easy to calculate that metric.
A rectangle is called a "module", if you mean the individual "pixels".
bytes per module = (bytes per qr) / (modules per qr) modules per qr = (17 + 4*version) ** 2 # or 25 in place of 17 if you want to include the margins
For a given QR size, version, and mode, it would be nice to be able to ask for the maximum number of bytes (assuming no compression). For example, after making a "QR" object,
qr.max_size(optional_mode=MODE_8BIT_BYTE)
. That way, instead of getting a DataOverflowError, you can split data into appropriate QR-sized chunks in advance.Right now, my code does a binary search using DataOverflowError, which is really dumb, and I'm sure it's not the only user code that would be improved.
Alternatively, you could directly allow making multiple QR codes from one buffer of data.