问题
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:
Here is a barcode once it has been printed, scanned and re-printed:
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"
回答1:
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 pixel-grazing and in the case of the scanned image this may be exaggerated due to ink-spread/bleed.
To demonstrate the effect of "ink-spread" I have superimposed your scanned image with an cleaner barcode:
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 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.
来源：https://stackoverflow.com/questions/31806061/how-to-produce-a-code-39-that-can-be-reliably-read-after-faxing