1. 33
    1. 11

      Reminds me of something with 3D printing: I quite regularly use a 45° rotation. It averages errors in both directions and it’s sometimes even a bit faster (because the nozzle can travel sqrt(2) faster).

      1. 2

        Great tip, thanks!

    2. 8

      If you hate reading long Twitter threads as much as I do, esp. on mobile: https://threadreaderapp.com/thread/1566421109255315458.html

      1. 3


    3. 5

      The takeaway here seems very wrong. The solution to this problem is to use one of the many barcode formats with built-in error tolerance. Missing a line of pixels should not destroy your data, when you’re probably gluing that barcode somewhere that people can scratch it. This is a design problem, not an implementation problem.

      1. 8

        OP here; I agree that error detection/correction would be better.

        Some context:

        • these events happened 20 years ago
        • the (hard to sway) customer specified the barcode format
        1. 4

          ∀ problems ∃ a solution that’s both perfect and unavailable ;)

          Seriously, if you’re going to print, it makes sense to print in such a way as to minimise the impact of the hardware’s weaknesses on the output makes sense. It’s like woodworking, where skilled people look at the wood before deciding where to saw, and decide in order to avoid weak spots in the result.

          You could make something else instead of the thing you’re making. Make a stool instead of a chair, or print something else. That something else would also be best done if you use your tools in a way that suits the materials and requirements.

        2. 1

          Aha, implicit project scope requirements defined by the customer. Sounds about right. ;-)

      2. 2

        Why not both?

        1. 1

          Because if you use a format with error correction, you never have to worry about your printer.

          1. 3


            1. 1

              No more than anyone does. If your printer fails, you’re hosed, but that’s easy to check. You don’t need a comment in your code that says “// Rotate barcode 90 deg for printing, to avoid dead lines”

    4. 2

      I currently work in a retail warehouse. Part of my job is dispatching customer’s larger items from the warehouse.
      I think around 3 or so years ago we transitioned to a system using PDAs with scanners instead of PCs with scanners and a POS system.
      The process usually goes: customer shows up, holds out their paper docket they got from the front counter, I scan the barcode, the order shows up on my PDA and I then scan the barcode on their item to verify its the one they ordered.

      Now the problem is the printers at the front counter are extremely unreliable. Sometimes bad resolution/blurry barcodes the scanners can’t pick up, sometimes issues like in this post, and sometimes they work fine.
      Unfortunately I just put up with it, falling back to manual input when it doesn’t work; somehow I think trying to convince corporate head office to rotate the barcodes or switch to QR codes with error correction on all dockets, across the country, isn’t worth my time.