Saturate a QR Code Symbol of a given version and EC level

[ghost]

Hello, kennytm. I'm not sure this is the correct venue to raise this issue. I apologies in advance if expressing this issue here is not appropriate.

When encoding is done using QrCode::with_version, push_optimal_data is used internally to dynamically select the best encoding for the segmented data. This makes the maximum amount of data a QR-code symbol can hold dependent on the nature of the encoded data.

Is it possible to determine this amount using this crate's public API? If not, is it possible to oversupply data to the encoder and determine how much of that data was successfully encoded?

Background information: I am working on an open source project that serializes binary data as a series of QR Code symbols. I need to keep the number of generated symbols to a minimum. There are constants on symbol dimensions and module size; and hence the requirement for a version limit.

Any help would be greatly appreciated.

[kennytm]

Hi,

The maximum amount of bits for each Version + EcLevel is not exposed to public for now, but you could refer to the table in

qrcode-rust/src/bits.rs

Lines 600 to 649 in 5e3a7ec

	// This table is copied from ISO/IEC 18004:2006 §6.4.10, Table 7.
	static DATA_LENGTHS: [[usize; 4]; 44] = [
	// Normal versions
	[152, 128, 104, 72],
	[272, 224, 176, 128],
	[440, 352, 272, 208],
	[640, 512, 384, 288],
	[864, 688, 496, 368],
	[1088, 864, 608, 480],
	[1248, 992, 704, 528],
	[1552, 1232, 880, 688],
	[1856, 1456, 1056, 800],
	[2192, 1728, 1232, 976],
	[2592, 2032, 1440, 1120],
	[2960, 2320, 1648, 1264],
	[3424, 2672, 1952, 1440],
	[3688, 2920, 2088, 1576],
	[4184, 3320, 2360, 1784],
	[4712, 3624, 2600, 2024],
	[5176, 4056, 2936, 2264],
	[5768, 4504, 3176, 2504],
	[6360, 5016, 3560, 2728],
	[6888, 5352, 3880, 3080],
	[7456, 5712, 4096, 3248],
	[8048, 6256, 4544, 3536],
	[8752, 6880, 4912, 3712],
	[9392, 7312, 5312, 4112],
	[10208, 8000, 5744, 4304],
	[10960, 8496, 6032, 4768],
	[11744, 9024, 6464, 5024],
	[12248, 9544, 6968, 5288],
	[13048, 10136, 7288, 5608],
	[13880, 10984, 7880, 5960],
	[14744, 11640, 8264, 6344],
	[15640, 12328, 8920, 6760],
	[16568, 13048, 9368, 7208],
	[17528, 13800, 9848, 7688],
	[18448, 14496, 10288, 7888],
	[19472, 15312, 10832, 8432],
	[20528, 15936, 11408, 8768],
	[21616, 16816, 12016, 9136],
	[22496, 17728, 12656, 9776],
	[23648, 18672, 13328, 10208],
	// Micro versions
	[20, 0, 0, 0],
	[40, 32, 0, 0],
	[84, 68, 0, 0],
	[128, 112, 80, 0],
	];

. The number of bits encoded can be tracked using Bits::len(), but it does not know if it has overflowed before pushing the terminator (as the EcLevel also affects how much data can be encoded).

If your data has fairly consistent encoding (e.g. all numbers), you could use http://www.qrcode.com/en/about/version.html to determine the upper bound for each symbol.

[ghost]

Unfortunately, the data is not not constrained to numerals or alphanumerics , so the maximums mentioned on qrcode.com and in the standard do not apply (or rather, they'll lead to wasting usable capacity).

For now, I'm brute forcing the optimal encoding via binary search. I'll take a second look at this problem and try to write a function that calculates this value if I manage to find some free time. If it's well-written enough to warrant sharing, I'll submit it to you to freely accept or reject.

Thank you for taking the time to write out a detailed response.