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

Posted 2023-03-31

【中文标题】如何生成可以在传真后可靠读取的 Code 39

【英文标题】：How to produce a Code 39 that can be reliably read after faxing

【发布时间】：2015-10-26 16:01:59

【问题描述】：

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

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

是否有最好的条形码类型，在打印、扫描和在其他地方重新打印后会产生最佳效果？

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

这是打印、扫描和重新打印后的条形码：

使用在线条形码阅读器进行测试会导致：

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

我正在使用 GNU 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"

【问题讨论】：

在某处上传原始条形码，以及扫描并重印版本的照片，并将它们链接到问题中

我明白了。我也同意这不是扫描仪/打印机质量问题（很可能是扫描仪）。对于大多数读者来说，这种缺陷（如抖动，但非自愿）将是一个问题。

您的条形码生成库是否允许您考虑墨水扩散/渗色。源图像和目标图像的主要问题之一是打印过程夸大了最窄空间的宽度。

@TerryBurton 好像没有这个选项。我已经用我正在使用的条形码生成库更新了这个问题。

关于更一般的问题，Code 39 的数据密度相当低，并且由于您启用了模 49 校验位，它应该可以相当可靠地扫描并且误读率很低。在这种特定情况下，您可能需要修改库以从条形宽度中减去一小部分固定量，以与您的流程兼容。

【参考方案1】：

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

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

您提供的图像的最大问题是最窄空间的宽度过小，导致条形码损坏。在源图像的情况下，这是由于像素掠过导致的过度“打印增长”（墨水扩散）。在扫描图像的情况下，这被夸大了，因为选择的 X 尺寸不足以承受端到端过程引入的成像缺陷。

为了展示打印增长的效果，我在您的扫描图像上叠加了相同数据的更清晰再现：

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

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

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

迁移到另一个线性条码符号系统不太可能有帮助，因为这些相同的问题可能会在更大程度上影响它。

this answer 中提供了有关生成高质量条形码的更多信息。