Proposal: Updates to the QR specification.

I'd love to know where one can formally make a proposed change to the QR code spec, a new version.

What I think is needed is these very simple changes.

1. The whitespace border of a QR code is defined as four units. This takes up a lot of space, and is ignored by a *LOT* of people. Clearly readers cope with only a one unit white border, so I'd like to see that defined as "valid" in the QR code spec, even if a four unit border is "recommended".

2. I'd like to see the padding after the end of the QR code content to be defined as allowed to be arbitrary unused data. This allows QR codes to be made with silly graphics in them and be 100% valid if done correctly. At present, this works, and people love doing this stuff, but technically is not what the padding should be.

3. I'd like to see an additional coding, using a base64 alphabet, coded (obviously) to 6 bits. The reason for this is that whilst QR codes can be used to carry binary data, they are more commonly embedded binary data as part of a format like JSON. Other formats like base45 are also used. Allowing a base64 alphabet means that raw binary data or embedded binary data in JSON, etc, can be coded 100% efficiently in the QR code, but is defined as printable text. It can be used for parts of JSON that are binary coded as base64. Even a 100% binary data QR code would read as a printable string if using such a coding, which is far easier to handle in general applications. Given the way codings work, this would be simple to add. It would mean base64 coding would be better than base45, for example.

4. I'd love to see UTF-8 make the default character coding.

Impact of these ideas?

The change of border, and padding data has basically no impact, readers already cope, so this is a no-brainer.

The additional of a new coding is more complex. It is not backwards compatible. However, it fits well with the possible use cases. The usage would be where raw binary would be better handled as printable data, and where using coding like JSON to carry binary data in parts. These are both cases that need a specific application to use the data. I.e. they are not some generic use case like a URL. So these are cases that are likely to be read by a specific application, and the application could be one that is designed to use a new version QR reader library. Even so, it probably makes sense for such a change to have a future date by which readers are expected to have been updated, and QR codes should not use the new coding before then unless intended to be used only with a specific application designed to read it. QR encoders should have an option to use the new version or not as well, obviously. The standard can state all of these objectives.

Now, daft question - where do I send my proposal?

P.S. I have had an email now confirming exactly how the process works, thank you (happy to quote you name, let me know). Also, I did not know this about my Datamatrix coder... "you wrote the Data Matrix library that was adopted by Zint and is probably (?) the most pervasive DM encoder in use today", nice.

Other ideas

One idea I did not mention, but do now as mentioned in that email, is the notion of an additional coding for URLs. This would be a subtly different set of characters to be URL friendly. For example, the "alphanumeric" alphabet coding has / and : and . but no ? or _ and no lower case. A new coding could make URL encoding better. Indeed, including a single character for "https://" even would make sense, or some other coding (like FC1) to indicate https:// at the start, would also make sense. It would take some research to work out the best way to do this, analysing lots of URLs.

Also, to be fair, anyone putting a URL in a barcode is mad to not do a bare minimum such as https://domain/argument which are all within the standard alphanumeric coding already (i.e. upper case) - putting a long complex URL in a QR code is generally a daft idea and makes for a big QR code anyway. A web server can easily handle a simple URL even if it then redirects to some more complex one internally. It is also worth having a short domain for such use.

The big issue I see with this, which is not a show stopper in itself, is that URLs tend to be used more generically - i.e. in the camera app on a phone, and not by specific applications. This would mean the new coding is no use until almost all readers understand it.

The good news is we live in a world of software updates, largely for security and vulnerability reasons, so things like a phone camera app would be updated. What is more difficult is hardware scanners, as used in supermarkets. But again, the good news is that those are generally used for specific applications that know what QR codes they are going to see and those QR codes could be coded not to use the new standard.