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?
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?