At the moment we have a type byte in the split main document QR codes. I originally planned to have such a tag in every QR code, which would allow us to:
Detect if someone scanned the wrong code and warm them appropriately (rather than producing random other errors).
Make auto-scanning of the PDFs easier in the future (we can scan all QR codes on the page then use the tags to figure out which code is which -- which would allow us to handle cases where the QR code scanner returns the codes in a different order to the expected order).
The only downside of this approach (aside from the minor increase in data payload) is that the document ID is no longer easily defined as being the last 8 characters of the checksum (because adding a prefix with the type information will offset all of the later bytes, changing the zbase32 representation). We can work around this but it would mean that our document IDs need to embed this PDF-specific information, which seems a bit ugly. This is the main reason I haven't implemented this yet.
Maybe we don't need tags for the checksums (it's obvious given the document we scanned)?
At the moment we have a type byte in the split main document QR codes. I originally planned to have such a tag in every QR code, which would allow us to:
The only downside of this approach (aside from the minor increase in data payload) is that the document ID is no longer easily defined as being the last 8 characters of the checksum (because adding a prefix with the type information will offset all of the later bytes, changing the zbase32 representation). We can work around this but it would mean that our document IDs need to embed this PDF-specific information, which seems a bit ugly. This is the main reason I haven't implemented this yet.
Maybe we don't need tags for the checksums (it's obvious given the document we scanned)?