barcodebarcode-printingcode39

How to produce a Code 39 that can be reliably read after faxing

My application is generating a Code 39 barcode but a customer is having problems with their document management system recognizing the barcode after the prints have been scanned and re-printed.

I have also tested it using an online barcode reader which confirms that the barcode on their end document is not readable.

Is there a best type of barcode to use, that would give the best results after printing, scanning and re-printing elsewhere?

Here is an original barcode in the PDF straight from the application:

enter image description here

Here is a barcode once it has been printed, scanned and re-printed:

enter image description here

Testing using an online barcode reader results in:

We are sorry, we could not found any barcode in the uploaded image.

I am using GNU Barcode to generate the barcode:

$ barcode -h
barcode: Options:
   -i <arg>     input file (strings to encode), default is stdin
   -o <arg>     output file, default is stdout
   -b <arg>     string to encode (use input file if missing)
   -e <arg>     encoding type (default is best fit for first string)
   -u <arg>     unit ("mm", "in", ...) used to decode -g, -t, -p
   -g <arg>     geometry on the page: [<wid>x<hei>][+<margin>+<margin>]
   -t <arg>     table geometry: <cols>x<lines>[+<margin>+<margin>]
   -m <arg>     internal margin for each item in a table: <xm>[,<ym>]
   -n           "numeric": avoid printing text along with the bars
   -c           no Checksum character, if the chosen encoding allows it
   -E           print one code as eps file (default: multi-page ps)
   -P           create PCL output instead of postscript
   -p <arg>     page size (refer to the man page)

Known encodings are (synonyms appear on the same line):
        "ean", "ean13", "ean-13", "ean8", "ean-8"
        "upc", "upc-a", "upc-e"
        "isbn"
        "39", "code39"
        "128c", "code128c"
        "128b", "code128b"
        "128", "code128"
        "128raw"
        "i25", "interleaved 2 of 5"
        "cbr", "codabar"
        "msi"
        "pls", "plessey"
        "code93", "93"
Solution

  • Code 39 is a low data density barcode that is tolerant of a wide X-dimension (the width of a narrow bar) and highly discriminating narrow-wide ratio (up to 1:3). As far as barcode symbologies go this makes it better suited than others at being transferred over a low resolution, noisy medium.

    The Code 39 standard permits the use of a modulo 43 check digit which reduces the possibility of misreads. I notice that this isn't present in your scanned image (although it is in your source image) so perhaps your system can be upgraded to accommodate this.

    The most significant problem with the images that you have provided is that the width of the narrow-most spaces is under-sized leading to a corruption of the barcode. In the case of the source image this is due to excessive "print growth" (ink spread) resulting from to pixel-grazing. In the case of the scanned image this has been exaggerated because the chosen X-dimension is insufficient to survive the imaging imperfections introduced by the end to end process.

    To demonstrate the effect of print growth I have superimposed your scanned image with an cleaner rendition of the same data:

    Superimposed Code 39 barcodes

    You can observe that towards the right hand side of the image that the narrow space between two adjacent narrow bars has been compressed out of the image to form a single wide bar.

    To improve things at source you can try the following:

    Migrating to another linear barcode symbology is unlikely to help as these same issues will probably affect it to an even greater extent.

    Further information about high-quality barcode generation is given in this answer.