Tools for QR-Code generation, not agree about standard limits?

1
votes

Question

There are (standard) size limits for strings presented by a QR-Code. Typical limits:

  • QR-Code of Version-1-L-Alphanumeric: 25 characters.
  • QR-Code of Version-1-M-Alphanumeric: 20 characters.

and there are software tools that transforms a input string into a image of the corresponding QR-Code symbol. These tools MUST respect the standard limits... But when you test any of these tools, they not respect...

They not agree about ISO standard limits? There are "another ISO"? There are a bug, or a risck of non-interpretation of symbols when using maximum sizes?

Context (at 2013-09) and explanations

When dealing with this problem, I was faced with a new problem: each tool have a different choice for size limits in the string for each QR-Code-Version.

If all QR-Code generator tool cumply the "QR-Code standard", ISO/IEC 18004:2006, Table 7, "Number of symbol characters and input data capacity"; all the tools MUST render symbols as stated by ISO standard. Examples:

  • string HTTP://BIT.LY/1234567890 have 14+10=24 characters, so, 24<25, the maximum for Alphanumeric Mode-L Version-1.

  • string HTTP://BIT.LY/12345 have 14+5=19 characters, so, 19<20, the maximum for Alphanumeric Mode-M Version-1.

    • googleapis/chart/qr: ok with 1234 but FAILS with 12345.

    • api.qrserver: ok with 1234 (good!), and good also with 123456 (remains Version-1), but fails with 1234567, because not changes to version-2 when have 14+7=21>20 characters.

... and so on, with many other QR-Code generator (ex. phpqrcode fails more!) and Version-1 limits.

That is a generalized bug? Or my expections (about standard compliance and QR-Code Generators behaviour) are wrong?

PS: until now, for my point of view, there are a lack of (ISO) standard compliance in the tools.

Glossary

  • QR-Code Generation Tool: any, online or offline, software tool that generate a QR-Code of a string, suppling as input the string and some parameters (typically version, EPS, charset and image size).

  • Encodable character set:

    • 8-bit byte data (binary): a complete set, UTF-8 or ISO 8859-1 charsets. Binary is the usual default charset of tools, with the UTF8 option.

    • alphanumeric data: a set of ASCII 44 characters (digits 0-9; upper case letters A-Z; nine other characters: (space), $ % * + - . / :). Usually tools not have this option, but a "auto-detected" behaviour, if the string is UPPER CASE, the charset is setted to alphanumeric.

  • ECL: Error Correction Level of the QR-Code. ECL-L (Low) is 7%, ECL-M (Medium) is 15%.

  • Version 1-L QR Code symbol: a symbol with 21 rows and with low (L) ECL. When encoding Alphanumeric data, the maximum length of encoded string is 25 characters.

  • Version 1-M QR Code symbol: a symbol with 21 rows and with medium (M) ECL. When encoding Alphanumeric data, the maximum length of encoded string is 20 characters.

References

Other links for ISO Standard Table-7 (copies and interpretations):

1
apiqr-code
Is the issue on the part of the QR generator, or on the part of the user who feeds non-compliant input into the QR generator? Misuse of a tool which does not purport to handle edge-cases is still misuse. – Joe Frambach
Hello Joe. Well, check if I understand your question... I am a user, I need a tool that meets the standards. The question is about "what is wrong? I (a misuse)? The tool (a bug)? the standard (it is another)?" – Peter Krauss

1 Answers

5
votes

There is one (not obsolete) ISO spec for QR codes, ISO 18004:2006. Most of what you observe is just lack of compliance. But there is one small part of the spec you are missing that explains the variance too.

First, why do some of these appear to encode too little info for a version and EC level? just a bug.

For example, the Google Chart implementation is quite old, not maintained, deprecated, and I know it has a few bugs. It was the basis for the encoder in http://code.google.com/p/zxing in 2008, and I know we fixed something like this a long time ago. zxing will not switch to the next version "too early" in your tests.

So how does api.qrserver appear to get too much info into a version 1 QR code? You're overlooking that you can switch modes in one QR code to further save bytes. This generator switch to numeric mode for the digits that end the string, and ends up saving enough to still fit into Version 1, EC level M, with 21 characters.

This is legal, although the optimization is not required. Choosing alphanumeric mode for the entire string is perfectly valid too, but will not yield the shortest possible encoding in some cases.