[FR] Encode QR data more efficiently

[wolflu05]

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

• [X] 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?

• [x] 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[bot]]

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.

[wolflu05]

I'd like to push this forward now. I understand that only numbers are not the right choice here as they could get easily mixed with normal GTIN Codes or other codes used by manufactures. Actually I like the idea from Oliver to just prefix it with INV-.

So I suggest the following scheme: INV-??x

• INV- is a constant prefix. We could later even make this configurable per instance to support users which work with items from different instances, so that when scanning we could show a warning that this QR code is not from this instance.
• ?? is a two character alphanumeric (0-9A-Z $%*+-./: (45 chars)) prefix, individual to each model. That means in theory we could support 45**2=2025 different models. (part => PA, location => LO, stock item => SI, build => BO)
• x the actual pk of the model. This means we would have 6 chars of overhead, and therefore could support the following amount of model instances with the following QR code modes:
  • v1 M ECL (15%) => 10**14 items (create ~1.902.587 items per minute for 100 years, until we need V2)
  • v1 Q ECL (25%) => 10**10 items (create ~190 items per minute for 100 years, until we need V2)

I'd like to implement this behind a server setting, which still defaults to the old format, but can be changed to the new. What is your opinion on this format?

---

I think implementing qrcode generation to the plugin interface with the barcode mixin is valuable, so that users could even provide their own format. And the proposed format can be implemented directly into the existing InvenTree barcode plugin which already handles parsing via the scan endpoint. (Generating the QR code data can later even being exposed to an api endpoint used for e.g. show a QR code preview in PUI)

[wolflu05]

ok, I found out, there is something called mixed mode for QR codes. Using mixed mode, data can be encoded using multiple formats in one QR code. That means that the first part can be encoded using the alphanumeric scheme and the second part using the numeric scheme. That results in the following updated stats, which are quite acceptable:

• v1 M ECL (15%) => 10**20 (old: 14) items (create ~3.170.979.198 items per second for 1000 years, until we need V2)
• v1 Q ECL (25%) => 10**13 (old: 10) items (create ~317 items per second for 1000 years, until we need V2)
• v1 H ECL (30%) => 10*3 (old: 4 got even worse*) items (create ~100 items per day for 10 days, until we need V2)