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
I'm generating a QR from a URL that has 48 ASCII chars and using Q redundancy, which should mean the total data size is 60 bytes. For that amount of data, this library generates a 37x37 version 5 QR. Looking at this chart, I can see that the capacity of a version 5 does correspond to 60 bytes in "binary" mode, but version 4 can accommodate 67 bytes in "alphanumeric" mode. This chart shows that that this set includes :, ., and / which is all that's needed for URL support, but it does not support lower-case chars. So now I'm mystified because I have a QR generated by a different system that is a version 4 and successfully encodes my URL containing lower-case chars with the correct degree of redundancy.
I suspect that this is due to the other system supporting mode optimisation, where the data can be split into chunks, each with a different encoding mode, for example if my URL contains https://www.example.com/ABC1234567890/XYZ, this could be encoded as a byte-mode chunk of https://www.example.com followed by an alphanumeric chunk of /ABC1234567890/XYZ, or possibly even finer chunks if 1234567890 could be dropped to numeric mode.
This page has an excellent demonstration of mode optimization along with a detailed description of how it works.
Do you have any plans to implement this optimisation so we can have smaller QRs?
The text was updated successfully, but these errors were encountered:
Synchro
changed the title
Excessive version selected
Excessive version selected, mode optimisation support?
Jul 6, 2022
I'm generating a QR from a URL that has 48 ASCII chars and using Q redundancy, which should mean the total data size is 60 bytes. For that amount of data, this library generates a 37x37 version 5 QR. Looking at this chart, I can see that the capacity of a version 5 does correspond to 60 bytes in "binary" mode, but version 4 can accommodate 67 bytes in "alphanumeric" mode. This chart shows that that this set includes
:
,.
, and/
which is all that's needed for URL support, but it does not support lower-case chars. So now I'm mystified because I have a QR generated by a different system that is a version 4 and successfully encodes my URL containing lower-case chars with the correct degree of redundancy.I suspect that this is due to the other system supporting mode optimisation, where the data can be split into chunks, each with a different encoding mode, for example if my URL contains
https://www.example.com/ABC1234567890/XYZ
, this could be encoded as a byte-mode chunk ofhttps://www.example.com
followed by an alphanumeric chunk of/ABC1234567890/XYZ
, or possibly even finer chunks if1234567890
could be dropped to numeric mode.This page has an excellent demonstration of mode optimization along with a detailed description of how it works.
Do you have any plans to implement this optimisation so we can have smaller QRs?
The text was updated successfully, but these errors were encountered: