Receipt printers are a complicated subject because of many variables. There are many different types of printers and ways to connect them, but this article will help you navigate most pitfalls.

The answers and suggestions in this article are all based on my libraries, which are open-source and freely available for anyone to use and experiment with. They are all part of the same family and work together, but of course you can also pick and choose some individual components.

Now I am not going to explain how these libraries are used, they have proper documentation. Also in the future I will write some more detailed articles about how these libraries will work together with some example code. So watch this space!

This is the sixth and final chapter of “The problem with User-Agent strings “. In the previous chapters, we’ve learned that the User-Agent string is something that web developers should handle with care. Handle with extreme care because it could blow up in your face at any time. But if you knew what you did, you could use it to get somewhat reliable information. We’ve also learned this changed during the last few years due to User-Agent reduction and compatibility issues. But at least there is a modern replacement: User-Agent Client Hints.

In this chapter, we’ll examine the current state of browser detection, whether it is accurate, and whether we should rely on it.

This is the fifth chapter of “The problem with User-Agent strings“. In the previous parts, we examined the history of the User-Agent string and browser vendors’ efforts to reduce its information. Removing details from the User-Agent string made passive fingerprinting much more difficult. 

These efforts have been really effective because we are now in a position where only the browser name, major version of the browser, and operating system name are reliable. The rest of the details in the User-Agent string are either definitely fake or potentially fake. In either case, we can’t rely on the data being accurate, so the best option is to ignore it.

But we’ve also seen some use cases where those details are helpful. For example, a download page for an application offering different builds based on CPU architecture or whether or not the operating system is running in 32-bit or 64-bit mode. 

How can we provide this information without sending it over the network with every request to every server we contact? The answer is the User-Agent Client Hints API.

In our fourth chapter of “The problem with User-Agent strings” we learn about some of the privacy advances that browsers have made in the last couple of years.

Privacy on the Internet has become much more important over the last decade. All the prominent browser vendors informally agreed to limit the potential user-identifying information in the User Agent string. 

As the creator of a popular browser detection library, I might say that browser vendors have been ‘plotting and scheming’ to reduce the amount of helpful information in the User-Agent string, and that makes my life quite a bit more complicated. 

But no. Privacy is essential, and there are certainly some excellent arguments in favour of this effort. 

In our third chapter of “The problem with User-Agent strings” we taking a look at the problems you run into when you change something in the User-Agent string.

As I mentioned in the previous instalment of this series, the User-Agent string is built upon layers and layers of lies. Sometimes, when I look at a modern User-Agent string, I feel like an archaeologist digging through the layers and determining what happened by looking at the context.

Despite those lies, we used to be able to tell quite a lot from a User-Agent string. But that has changed in the last couple of years.

In our second chapter of “The problem with User-Agent strings” is a fascinating story about the browser wars. It’s a tale where the User-Agent string takes centre stage, revealing its unpredictable nature and the need for vigilance when relying on it. 

The tale starts with me buying a new car back in 2016. Now, I didn’t pick this car—a Volvo V60—because it had an entertainment system with a built-in browser, but it definitely was one of the first things I checked out after I took it home. Priorities.

Nowadays, having a proper browser in your car isn’t a big deal, but it was still relatively rare back then. When I got home, I put the browser through its paces. And it was horrendous. It was slow. It couldn’t render modern web pages. The one redeeming thing this browser had was its User-Agent string. Or, actually, it’s two User-Agent strings.

In our first chapter of “The problem with User-Agent strings” we are taking a deep dive into history and start with the basics of the User-Agent string. 

Our first stop is in 2018, with the release of Firefox 60. There is nothing significant about this specific release—I could have chosen pretty much any version—but we have to start somewhere.

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0

So what do we have here? At the back of the User-Agent string we can see our browser, Firefox, version 60. It uses the Gecko rendering engine, and we can tell it’s Windows 10 because it uses version 10 of the Windows NT kernel. We see that it uses WOW64, which means it runs as a 32-bit application on a 64-bit version of the operating system. 

The Modern FrontEnds conference was held last week in London. It wasn’t a small conference, as the website touts over 100 speakers and more than 3000 developers attending. Not only that, the conference had some big sponsors and a hefty ticket price. 

But before the conference even began, I heard about some serious issues with how the organisers treated their speakers. That immediately raises some red flags. After the event, some speakers spoke publicly about their experiences. 

Now, I wasn’t there. I spoke at a different event in London the day before. But I chatted with some of the Modern FrontEnds speakers about this. And it still feels weird commenting about a conference I did not speak at or even attend. So I am not going to do that.

I bought an Apple Studio Display. But unlike most people, I intend to use it for my Windows machine, which does not make much sense but hear me out.

I run Mac and Windows because I develop software for both Mac and Windows and am currently using an ageing iMac Pro and a pretty good HP Elitedesk Mini connected to an awful Samsung M7 display. The only thing okay about that monitor is its size and resolution: 4K at 32 inches, but otherwise, it is terrible.

Once the Mac Studio becomes available again, I intend to buy one to replace my iMac Pro. But I had the opportunity to order one for pickup on day 1 of the Studio Display launch date. So I did. I figured I could use it for my upcoming Mac Studio, but in the meantime, it would be an excellent replacement for that terrible Samsung display. And now that I tried it, I think I might need to buy another Studio Display for the Mac Studio. I am now spoilt, and there is no way to return to that awful Samsung display.