Heard from a friend of Seagate. A user reported that the laptop would crash every time he played Li Na's Qinghai-Tibet Plateau. After testing, it was found that when singing to the end of "That is the Qinghai-Tibet Plateau..." (YouTube), the hard disk resonated, the amplitude was so large that the read/write head could not read the data. In order to catch this bug, the friend listened to Qinghai-Tibet Plateau for a month...

When I first saw this joke (source from ZhiHu: Are there any bugs that make you dumbfounded? - wuz's answer), I just smiled. However, I never thought that I, a frontend developer, would encounter a hardware problem.

Problem Description

A business requirement from the team next to us: print a bunch of barcodes (such as product IDs) on special paper in batches, then tear them off and stick them on the package for easy subsequent operations. Since the shipping label platform I am responsible for has some extensibility, they decided to let us support the barcode function (so they don't have to write code to draw, and it's also convenient to change the business).

I spent two or three days to support it. After passing the local test, I thought I could sleep well. However, they reported a bug: most of the barcodes printed out could not be scanned, and some barcodes could only be scanned by PDA devices, but not by ordinary scanners.

The requirement cannot be delayed, and the bottleneck is now on me. I have never encountered such a problem before, so I don't know how to start. I had to run to their side to see what was going on.

Troubleshooting

First, I got some barcodes they printed before and found that there were severely jagged edges (the following image shows a small part of the barcode). Many barcodes were almost black due to the jagged edges and narrow spacing, but some barcodes were printed perfectly without any jagged edges. The colleagues said that there was no problem when the frontend drew themselves using JSBarcode before, but it has been like this since they switched to the shipping label platform. However, the PDF generated by the shipping label platform will never have this problem, otherwise there would have been various live incidents in the past two years.

Generally speaking, the cause of jagged edges is that the resolution of the image sent to the printer is too low (printing requires 300 DPI, while the general computer requires 72 DPI). However, since all our units are unified in centimeters, and the backend uses Chrome to render and generate the PDF, the effect should be similar to Word, and it is well known that a printed Word will not have this problem.

Failed Attempts

To determine where the shipping label started to jag, I found the responsible person for their frontend, backend, and printing plugin, analyzed all the traces, and troubleshooted the problem step by step:

• The PDF generated by the shipping label platform: ok
• The PDF data received by the backend: ok
• The data they sent to the printing plugin: looks ok
• The effect of the printer: jagged edges

So we focused on the printing plugin. They used an open-source printing plugin (mostly C code) and encapsulated it. Considering that looking at these codes might shorten my life, I decided to give up and think about other ideas.

An Effective Solution

In the process of consuming brain cells, I suddenly noticed that the text also had jagged edges. So I asked their QA for various shipping labels that had been printed during the test a long time ago, and found that they all had this problem (this barcode is perfect, but the text has jagged edges):

At this point, some of you may have guessed the reason: the printer does not support grayscale printing, it can only print pure black and pure white. For gray areas, the printer will use the density of black and white dots to display a visual effect. For PDF, texts have anti-aliasing (sub-pixel rendering), so when sub-pixel rendering disappears due to the printer, it becomes like this. The barcode image is the same. If the barcode image (PNG) has gray pixels on the edge of each bar due to scaling, similar problems will occur.

And I instantly thought of why the barcode drawn by JSBarcode was fine. I used that library when I was in their team before. It generates an SVG element, and when Chrome renders it, if the unit of the positioning information of an element is pixels, all numbers will be rounded. For example, if you set left: 5.8px; width: 10.2px, then you will only get left: 6px; width: 10px in the end. As long as the positioning information of each rectangle is an integer, there will be no sub-pixel rendering problem in the end.

I discussed with our backend, replaced the barcode-related generation code with the SVG version, and the team printed it several times again. The barcode no longer has jagged edges.

Is the Problem Over?

Due to the rapid solution to the problem, I was in a good mood and decided to go to Saizeriya with my colleagues in the evening. However, just before we were about to get off work, they reported another problem: although the barcode looked fine when printed, only PDA devices could scan it, and the ordinary scanner still couldn't. My brain: __________________.

At this time, the boss of the team happened to pass by and asked me how the barcode was generated, and whether it would cause a long bar to shift by one or two pixels due to the algorithm. However, I quickly printed it with the company's high-quality printer, and roughly compared the printed barcode (see the following image) with the one generated by the online generator I found on Google. With my good eyesight, it seems that I can't see any significant difference. And the barcode should have very good fault tolerance. Even if it shifts by one or two pixels, it should be recognized, otherwise scanning will be extremely difficult for cashiers.

The Truth

When you have eliminated the impossibles, whatever remains, however improbable, must be the truth. - Sherlock Holmes

As the saying goes, after eliminating all possible problems in a very short time, only one possibility remains: the QA's handheld scanner has a problem.

Because I didn't want to stand my colleague up, and I didn't want my colleague to wait for too long, I took a picture of the back label of the scanner and slowly checked it while waiting for the meal at Saizeriya. The model of this scanner is Orbit MS7120. I searched for its parameters and felt that there was nothing special. So I joked with my colleague, "Is it possible that this weird scanner can only scan a minimum of three characters?" I also Googled orbit ms7120 3 chars, and the first result was a link: MS7120 Orbit - How to configure code 128 to decode a minimum of three characters. My brain: __________________.

The article says:

By default, the MS7120 Orbit can only scan a minimum of four characters for code128 barcodes. If you want to change it to a minimum of three characters, click here to download a PDF, then scan each barcode in order. Note that this will reset your device.

Who am I? Why do I need to set it to a minimum of three characters? I feel like that guy who sent the wrong photo for the computer level 2 exam certificate.

Jokes aside. To verify whether my guess was correct, after finishing Saizeriya, I returned to the company and tried the method in the PDF. It really could scan a barcode with three characters... However, I searched the manual of MS7120 for a long time, without finding how to make it support barcodes with any number of characters.

Because this requirement may have a risk of delay, they sent an email and @ me. In order not to be "sitting at home, the blame comes from the sky", I quickly replied to the email and attached my complete verification steps. The solution I gave was "Don't use barcodes for data with less than 4 characters. If this requirement must be met, add some blank characters to make the length at least 4".

Postscript

1. The next day, their QA came over and said, "Did you mess up with the scanner?" Me: "Well, I debugged it last night, now I'll help you restore the factory settings..."
2. Later, they asked the business team to try with their own scanner, and it could be scanned. Therefore, no one needs to change the code, and this problem is considered solved.