soledad penadés

In addition to learning to optimise builds when using big imports with Vite, I also wrote a lot of notes while building store store cards, to expand on them at some point... and that happens to be now!

NOTE: when I talk about "barcodes" in this post, I will refer indistinctly to both 1D (with vertical lines) and 2D (with a matrix layout) barcodes.

Barcodes are almost everywhere

When I started building the app I was barely thinking about barcodes in general, or paying much attention to them.

But I needed to verify that what I was scanning and rendering was the proper format and data, so I started to get ahold of as many cards and with as many different barcode formats as possible, to test they scanned and rendered correctly.

This trained my eye to quickly locate where the barcode was and align it with the camera to quickly scan, and then it also led me to start noticing barcodes almost everywhere, and not just in loyalty cards or obvious places such as flight boarding passes or train tickets.

My favourite part is that because they use standard barcode formats, you can scan them and see what is encoded in them.

Some examples:

• pretty much any object you can buy nowadays will have a barcode built-in into its packaging already, because it makes scanning at the till¹ much faster than manual entry.
• parcels in the UK have several barcodes (at least the ones I've received), with different pieces of information—some of them being your literal address and postcode. So if you want to make sure you don't want to associate your rubbish with your address, destroy the entire label before disposing of the packaging, not just the readable name and address. In particular, they seem to contain:
  • a data_matrix barcode with a lot of strings including your full address postcode, tracking number and the "customer reference" label data (my guess is that this is used for logistic and sorting centres so the post can be routed automatically with conveyor belts and laser scanners).
  • a code_128 barcode with the tracking number (I think this is what the delivery person scans).
• the rubbish and recycling containers in the streets in Valencia have a barcode (although I don't remember what was on them).
• some of the newest postage stamps also have a barcode:
  • in the UK they are meant to be used to track where the package is...
  • although the US stamp I scanned seems to have random gibberish which might make sense to their systems only

I also became WAY more aware of barcode formats

Before, a barcode was "just a barcode" to me. I was aware that there were 1D and 2D versions, but that was it.

However, I started to appreciate the different formats that are out there, and I realised that not every 2D code was a QRCode!

Examples of some popular ones (images from the MDN Barcode Detection API doc):

code_39

code_128

datamatrix

QRCode

Aztec

If you had asked me before I started doing this, I would have said that all of the three last ones were "QRCodes". But they aren't! Visually they're quite different, once you look at them side by side. The datamatrix has the border on the left and bottom sides, the QRCode has those three squares on the top left, top right and bottom left corners, and the Aztec has the characteristic square in the centre which also gives it the name (as an Aztec pyramid).

It was funny when I would spot an unusual barcode when we were going out and about and, suddenly, exclaim:

Oh! An Aztec code! Look! It has the square pyramid in the centre!

... much to my partner's amusement!

I also started noticing some patterns in usage

It seems that categories of organisations tend to use the same barcode format(s).

For example, I saw libraries using Codabar, supermarkets using code_128, etc.

I suspect there might be a very mundane reason underneath such as that they all use the same software or technology vendor to manage the cards.

And that's not even considering the most influential factor: the longer and more complex pieces of data you need to encode, the more likely you are to end up using a 2D barcode format rather than a simple 1D vertical barcode.

Some examples of type of organisation and card format I've noticed:

• Libraries:
  • codabar (Westminster, A... 14 digits...B; Camden, A... 14 digits... B)
  • code_39 (Valencia, one letter + 9 digits - an outlier?)
• Supermarkets & stores:
  • code_128: John Lewis (22 digits), Waitrose (16 digits), Tesco (16 digits), Paperchase (18 digits)
  • ean_13: Foyles (13 digits)
• Museums & other entertainment venues:
  • code_128: Southbank Center (one letter + 8 digits), TATE (16 characters with letters and numbers)
  • code_39: climbing centre (6 digits)

There is sometimes extra data in the barcodes, which is not visible to the naked eye

Barcodes often include a text version of the encoded data, underneath the vertical barcode itself. From what I understand, the text version should be printed using a specific font-face which is optimised for Optical Character Recognition²—or at least it should have been in the earliest barcode formats.

But I have seen many cases which don't use that font even when rendering an "old" format, which makes me think that those texts are not meant for machines anymore but for a human to read.

For example, when you have to key in the barcode by hand in a self-service till when the machine won't scan the number, because the label is slightly crinkled or warped.

And then I was a bit surprised to realise that the barcode itself sometimes contains slightly more data than what is printed in the label. For example, my library cards only have a number such as 01234567 printed on them, but when you scan the barcode, it reads as A01234567B (i.e. the number is "sandwiched" between an A and a B).

This isn't a problem until you rely on a person to double check that what was scanned matches what the card says: they might say it doesn't, because there are two extraneous characters!

Of course people can be trained and learn to only look for the relevant data in the physical card if it's using a 1D code, as they tend to encode much less data, but it is just very extremely difficult to assess that the detected data is right when using 2D barcodes: they tend to encode really long strings and sometimes there's no reference number underneath to double check it's been scanned correctly.

Go and read an Aztec code with your eyes. I'll be here waiting to see what you can find!

Full-sized vs mini cards: a form of A/B testing?

When you sign up to their loyalty program, some supermarkets (at least in the UK) issue you with a full-sized card (which might be using a complex 2D format such as Aztec) and then a strip of smaller minicards (or so I call them) featuring a simpler format such as code_128, which you're then able to tear apart and append to your physical keyring(s) using the small hole that is perforated in them, so that the card is always handy³.

Interestingly, I noticed that the data encoded in the cards was not exactly the same, although they shared a prefix.

For example, I saw this from a supermarket:

• Full size card, with an Aztec code: has a series of semicolon-separated pieces of data, one of them being 0123456700
• Minicard, with code_128: encodes 0123456701

Notice that they only differ on the last digit.

It made me wonder if in actual fact your membership number is just the prefix (01234567) and then the last 00 and 01 is used to track which card variant you're more likely to use. So, a sort of A/B test hidden in plain sight.

Of course I could log into the supermarket's website and see if it tells me what my membership number is, and then I could verify my suspicions, but I haven't gone that far.

Related: minicards are very hard to scan with a webcam

They really seem to be designed to be scanned with a laser scanner instead.

With a webcam, or a phone camera, it is a matter of luck that you manage to successfully scan those cards. The text is very small to start with, the lines can sometimes have a bit of a blurry edge, and I suspect there's often no sufficient separation between the lines to look different enough that they scan clearly.

Add to that that the focus of the camera cannot be controlled using Web APIs, so even if the device could be adjusted to better focus on the barcode in question, it won't; it's just set to an average focal distance.

To complete the lethal combo, these mini cards are often laminated with a layer of glossy plastic, which is good for increased durability⁴, but on the other hand it makes them glary, and that can be quite deadly when trying to scan them with these non-specialised devices such as webcams or phone cameras: they rely on analysing pixel values, and the pixel values rely on the reflected light in the environment, and the reflected light depends on the surface the light in the room hits.

Then, if the surface is very smooth and polished, it will mirror the source of light and rather than the actual black or white value, the camera will register white in the areas with glare.

And finally: scanning will fail 😩

Suggested reading

Now that you know a bit more about barcodes, I totally want you to read this page in which eta reverse enginered digital rail tickets in the UK. It's a truly engrossing read! I love seeing and reading about the lengths that very dedicated people will go to when sufficiently intrigued about something.

And of course I encourage you to visit store store cards and scan as many barcodes as you can find. Did you find any new pattern I didn't notice?