如何生成可在传真后可靠读取的Code 39

Question

我的应用程序正在生成Code 39条形码，但客户在扫描并重新打印照片后，文档管理系统会识别条形码时出现问题。

我还使用在线条形码阅读器对其进行了测试，该阅读器确认其最终文档中的条形码不可读。

是否有最好的条形码可供使用，在其他地方进行打印，扫描和重新打印后会产生最佳效果？

这是PDF中直接来自应用程序的原始条形码：

打印，扫描并重新打印后，这是条形码：

使用在线条形码阅读器进行测试可以得到：

  

很抱歉，我们在上传的图片中找不到任何条形码。

我正在使用GNU条形码生成条形码：

$ 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"

Answer 1

Code 39是一种低数据密度的条形码，可以容忍宽X维（窄条的宽度）和高度区分的窄宽比（最高1：3）。就条形码符号而言，这使得它在通过低分辨率，嘈杂的介质传输时比其他符号更适合。

Code 39标准允许使用模43的校验位，以减少误读的可能性。我注意到您的扫描图像中没有这个（虽然它在您的源图像中），所以也许您的系统可以升级以适应这种情况。

您提供的图像最重要的问题是最窄的空间的宽度不足以导致条形码损坏。在源图像的情况下，这是由于像素放牧，并且在扫描图像的情况下，这可能由于墨水扩散/出血而被夸大。

为了展示“墨水扩散”的效果，我将扫描图像与更干净的条形码叠加在一起：

您可以观察到，在图像的右侧，两个相邻窄条之间的狭窄空间已被压缩出图像，形成一个宽条。

要在源头改进，您可以尝试以下方法：

• 通过确保执行条形码生成来避免像素放牧，以便将符号的X维度设置为输出设备的原始分辨率的倍数 - 这个过程有时称为“网格拟合”。
• 通过修改GNU条形码库以从条宽度中减去一小部分固定量来补偿墨水扩散，以便与您的打印和扫描过程兼容。
• 将条形和间距的窄宽比最大化为1：3。
• 最大化您的X维度。

迁移到另一个条形码符号系统不太可能有所帮助，因为这些相同的问题可能会对其产生更大的影响。

有关高质量条形码生成的更多信息，请参见this answer。