2

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"
Terry Burton
  • 2,801
  • 1
  • 29
  • 41
Jack
  • 515
  • 1
  • 5
  • 17
  • upload the original barcode somewhere, along with a photo of the _scanned-and-reprinted_ version, and link them in the question – tompave Aug 04 '15 at 10:01
  • I see. I, too, agree that is't a scanner/printer quality issue (most likely, the scanner). That kind of imperfections (like dithering, but involuntary) would be a problem for most readers. – tompave Aug 04 '15 at 12:16
  • Does your barcode generation library allow you to account for ink-spread/bleed. One of the main problems with both source and destination images is that the width of the narrowmost spaces is under-exaggerated by the print process. – Terry Burton Aug 04 '15 at 13:09
  • @TerryBurton It doesn't seem to have such an option. I've updated the question with the barcode generation library that I'm using. – Jack Aug 04 '15 at 13:42
  • Regarding the more general question, Code 39 has fairly low data density and since you have enabled the modulo 49 check digit it should scan fairly reliably and have a low misread rate. In this specific case you may need modify the library to subtract a small, fixed amount from the bar widths to be compatible with your processes. – Terry Burton Aug 04 '15 at 13:58
  • Before doing this however you should try putting the output of a generator that can compensate for inkspread through your end-to-end process to see whether this will really solve your client's problems. You can use the EPS output of the following as a starting point with different values of inkspread: http://www.terryburton.co.uk/barcodewriter/generator/?submit&encoder=code39&data=1474747&options=includecheck%20inkspread=0.3 – Terry Burton Aug 04 '15 at 13:58
  • Actually just to point out that the scanned barcode *does not* include a modulo 43 check digit whereas your original does... – Terry Burton Aug 04 '15 at 15:44
  • My application uses option `-c` (no Checksum character, if the chosen encoding allows it) because the customers document management system (DocuWare) does not support them. – Jack Aug 04 '15 at 16:48
  • @Jack Did you find the answer useful or did it miss the mark? If useful please upvote or accept. – Terry Burton Aug 09 '15 at 12:26

1 Answers1

5

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:

  • Avoid pixel-grazing by ensuring that the barcode generation is performed so that the X-dimension of the symbol is set to a multiple of the output device's native resolution – a process sometimes referred to as "grid-fitting".
  • Compensate for ink-spread by modifying the GNU Barcode library to subtract a small, fixed amount from the bar widths in order to be compatible with your printing and scanning processes.
  • Maximise the narrow-wide ratio of the bars and spaces to 1:3.
  • Maximise your X-dimension.

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.

Terry Burton
  • 2,801
  • 1
  • 29
  • 41