This set of patches tries to produce a more optimally reduced URL/ QR Code representation for the MySchedule links.
Principle of Operation:
We first use deflate to reduce bitstream to a minimum. Unfortunately that gets us a binary bitstream which can't be encoded into a URL, so we need to use an expanding encoding to fit the data into the URL-safe characters.
We chose to use a Base32 scheme for this which will fit it into the QR codes 'Alphanumeric' encoding alphabet, as a result of this, 5 bits in the deflate stream should take 5.5 bits on the QR code bitstream.
The downside of this is that I couldn't find a react qr component which supports using different encoding schemes for different segments of the QR code data (allowed by the QR standard). Additionally the Qr component currently used by conclar only supports the full eight-bit encoding scheme, so I have swapped the whole component for react-qr-pretty
at the cost of a different size of presentation of the QR code on the page.
As a result, the whole URL has to be rendered as upper case, it wouldn't be impossible to add the multi-segment feature to a react QR component but I felt it was out of scope for this PR.
The URL generated also uses a different subpath from the non-compressed one so that even if compression on codes is switched off both forms of URLs can be accepted, allowing conventions using thissoftware to switch modes without invalidating 'released' QR codes.
Coding Choices.
I've tried to keep the changes to conclar as small as possible to implement this feature. Instead of making intrusive changes to ItemByIdList.js, I've copied it and added the changes to GzItemByList.js It should be possible to combine them if that was considered a good idea.
This set of patches tries to produce a more optimally reduced URL/ QR Code representation for the MySchedule links.
Principle of Operation:
We first use deflate to reduce bitstream to a minimum. Unfortunately that gets us a binary bitstream which can't be encoded into a URL, so we need to use an expanding encoding to fit the data into the URL-safe characters. We chose to use a Base32 scheme for this which will fit it into the QR codes 'Alphanumeric' encoding alphabet, as a result of this, 5 bits in the deflate stream should take 5.5 bits on the QR code bitstream.
The downside of this is that I couldn't find a react qr component which supports using different encoding schemes for different segments of the QR code data (allowed by the QR standard). Additionally the Qr component currently used by conclar only supports the full eight-bit encoding scheme, so I have swapped the whole component for react-qr-pretty at the cost of a different size of presentation of the QR code on the page.
As a result, the whole URL has to be rendered as upper case, it wouldn't be impossible to add the multi-segment feature to a react QR component but I felt it was out of scope for this PR.
The URL generated also uses a different subpath from the non-compressed one so that even if compression on codes is switched off both forms of URLs can be accepted, allowing conventions using thissoftware to switch modes without invalidating 'released' QR codes.
Coding Choices.
I've tried to keep the changes to conclar as small as possible to implement this feature. Instead of making intrusive changes to ItemByIdList.js, I've copied it and added the changes to GzItemByList.js It should be possible to combine them if that was considered a good idea.