[FR] Encode QR data more efficiently

[wolflu05]

Please verify that this feature request has NOT been suggested before.

• I checked and didn't find a similar feature request

Problem statement

Current QR codes encode lots of unnecessary data, and even in binary format (which requires much more bits per char) which causes higher version QR codes more modules => larger grid => cannot be printed that small. This especially happens with stock location QR codes because they encode the most of unnecessary data, and even an id with only one char already requires a v2 QR code

1. {"part": 9} (11 chars) => v1
2. {"part": 99999} (15 chars) => v2
3. {"stocklocation": 9} (20 chars) => v2
4. {"stocklocation": 99999999} (27 chars) => v3

QR version overview

Source

Comparison

	Part	Location	Stockitem	Buildline
QR code data (base coast/ extra bytes)	{"part": ID} (10)	{"stocklocation": ID} (19)	{"stockitem": ID} (15)	{"build": ID} (11)
V1 21x21 (max: 14)	4	-	-	3
V2 25x25 (max: 26)	16	7	11	15
V3 29x29 (max: 42)	32	23	27	31

The cells show the max digit count of which an ID can consist to work with that version of QR code

Suggested solution

I suggest to reduce the size of unnecessary data and either add the ability to increase the ECL level from M (15%) to something like Q (25%) or even H (30%) while still staying with a V1 QR code for all types currently available. And to still keep backwards compatibility I suggest we add a toggle to the settings to decide which type to use. And for scanning systems (web UI, app, ...), we could easily support to read both types.

For encoding the data a bit more sparingly I have two ideas:

1. Still use the RAW (binary) QR type and just prepend one char. E.g. P9999 (part)
2. Since our ids are only numbers, we could easily use the numeric encoding and prepend one or even two digits (to be save for the future) to indicate the QR type

	Idea 1	Idea 2
Data	P9999	019999
v1 L (7%)	16	39
v1 M (15%)	13	32
v1 Q (25%)	10	25
v1 H (30%)	6	15

The cells show the max digit count of which an ID can consist to work with that version of QR code

Describe alternatives you've considered

/

Examples of other systems

I'm not sure how other systems efficiently encode their data in QR codes, but I'm sure we're not the first ones. Maybe there is even a efficient standard we could use?

Do you want to develop this?

• I want to develop this.

[SchrodingersGat]

@wolflu05 I'm on board, it would be a good idea to improve our QR system for better printing.

Preserving backwards compatibility is obviously necessary, but mostly on the "scanning" side.

I suggest we add a toggle to the settings to decide which type to use.

Good idea, we could default to the new style, and allow users to preserve old style, potentially

I would suggest that we make the new codes a bit more unique, though. Perhaps an INV- prefix, or something? Having a simpler alphanumeric code as you suggest increases the risk of collision with other third-party barcodes

[wolflu05]

I seem to remember that @matmair has tried to standardize things across inventory software. Maybe you know something/have some ideas in this area too, on how qrcodes can be standardized across inventory software while trying to fit the required data into a v1 QR code with abilities to increase the error correction level.

[matmair]

The standard is to use EAN or G1 codes but that will take more space than your suggestion. This could be combined with #5208 / a generic reference model to make this useable for plugins too
Edit: that would need a v2 but provide enumeration protection

[wolflu05]

But aren't ean/gtin numbers just 13 digits so they would fit in a v1 qr? And as they are all numbers, they would even fit in a number type qr with 30% error correction.

[matmair]

Sorry I was unclear; typeIds would need v2, they are at least 28 chars

[wolflu05]

They then even would need v3, because 15% error correction would be minimum in my opinion (max 26chars) . Higher ECL would be even better. So when we do it, we should make typeids optional as a third encoding type next to the current behavior and something short for small qrs (this issue).

[github-actions]

This issue seems stale. Please react to show this is still important.

[wolflu05]

I still need to find a better solution for this. It's definitely on my roadmap.