问题描述
我的应用程序正在生成Code 39条形码，但是客户在扫描和重新打印打印件后，其文档管理系统在识别条形码时遇到了问题.
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?
以下是直接来自应用程序的PDF中的原始条形码:
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:
我正在使用GNU条形码生成条形码:
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"
推荐答案
代码39是一种低数据密度条形码，可以容忍宽X维度(窄条的宽度)，并能高度区分窄幅比例(最高为1:3).就条码符号而言，这使其更适合通过低分辨率，嘈杂的介质进行传输.
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.
Code 39标准允许使用模43校验位，以减少误读的可能性.我注意到，这在您的扫描图像中不存在(尽管它在您的源图像中)，所以也许您的系统可以升级以适应此情况.
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:
- 通过确保执行条形码生成操作，从而将符号的X维度设置为输出设备的原始分辨率的倍数来避免像素掠夺，该过程有时称为网格拟合". li>
- 通过修改GNU条形码库以从条形码宽度中减去少量固定量来补偿墨水扩散，以便与您的打印和扫描过程兼容.
- 将条形图和空格的窄宽比最大化为1:3.
- 最大化您的X维度.
迁移到另一个条形码符号体系不太可能会有所帮助，因为这些相同的问题可能会在更大程度上影响它.
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.
这篇关于如何产生可以在传真后可靠读取的Code 39的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！