还有一些其他信息：

Question

我有一台 GoDEX RT700i 打印机（203 DPI），我想在Linux中打印条形码（Ubuntu 16.04）我的条形码是PDF格式。条形码下面有一个8位数字。

在Windows中，GoDEX驱动程序没有问题。条形码和数字印刷完美。注意：如果我从谷歌浏览器打印PDF，它看起来很好，但如果我从Adobe Acrobat Reader打印PDF，它看起来像在Linux中。

在Linux中，当我打印条形码时，数字的数字是正常的，与Windows相同，并且条形的高度也可以，但每个条形的宽度都大于pdf中显示的宽度。

我该如何解决这个问题？

Here a photo of the printed barcodes
左边的一个用Linux打印，另一个打印在Windows中。

还有一些其他信息：

对于Linux我已经为 CUPS 编译并安装了GoDEX驱动程序，然后我通过AppSocket / HP JetDirect添加了带有IP和端口（9100）的打印机。
然后，我选择PPD文件godex-rt-700i.ppd

这两行是在ppd文件中。也许他们与这个问题有关：

 TTRasterizer: Type42
 *cupsFilter: "application/vnd.cups-raster 50 rastertoezpl"

当我发送打印订单时，我意识到该作业有3个过滤器：

pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
gstoraster (application/vnd.cups-pdf to application/vnd.cups-raster, cost 99)
rastertoezpl (application/vnd.cups-raster to printer/GODEX-RT700i, cost 50)

在 rastertoezpl.c 文件中，我看到有一个函数（ GDXCompress ）压缩Godex打印机的输出行。我以为压缩可能会以某种方式影响条形码，我试图停用该功能（ CompBuffer = NULL ）并重新编译驱动程序，但这并没有解决任何问题。

这些是每个过滤器的输出：

All files（原始和中间产出）

当我发送original PDF file进行打印时，这两个文件是由 / var / spool / cups / 中的杯子生成的：
d00122-001 （pdf）
c00122 （未知）

1。 pdftopdf （/ usr / lib / cups / filter / pdftopdf）：
/ usr / lib / cups / daemon / cups-exec -g 7 -n 0 -u 7 none / usr / lib / cups / filter / pdftopdf MY_PRINTER 122 my_user 00000378 1“PageSize = Custom.56.69x65.20 Collate ColorModel = Grayscale Duplex = None job-uuid = urn：uuid：7f84fc46-1965-35d2-6a72-e2e73ab0264b job-originating-host-name = localhost date-time-at-creation = date-time-at-processing =创建时间= 1488464765 time-at-processing = 1488464765“/ var / spool / cups / d00122-001＆gt; output_pdf2pdf.pdf
output_pdf2pdf.pdf （pdf）

2.gstoraster（/ usr / lib / cups / filter / gstoraster）：
/ usr / lib / cups / daemon / cups-exec -g 7 -n 0 -u 7 none / usr / lib / cups / filter / gstoraster MY_PRINTER 122 my_user 00000378 1“PageSize = Custom.56.69x65.20 Collate ColorModel = Grayscale Duplex = None job-uuid = urn：uuid：7f84fc46-1965-35d2-6a72-e2e73ab0264b job-originating-host-name = localhost date-time-at-creation = date-time-at-processing =创建时间= 1488464765 time-at-processing = 1488464765“
output_gstoraster.ras （ras）
该文件可以通过rasterview程序打开

3.rastertoezpl（/ usr / lib / cups / filter / rastertoezpl）：
/ usr / lib / cups / daemon / cups-exec -g 7 -n 0 -u 7 none / usr / lib / cups / filter / rastertoezpl MY_PRINTER 122 my_user 00000378 1“PageSize = Custom.56.69x65.20 Collate ColorModel = Grayscale Duplex = None job-uuid = urn：uuid：7f84fc46-1965-35d2-6a72-e2e73ab0264b job-originating-host-name = localhost date-time-at-creation = date-time-at-processing =创建时间= 1488464765 time-at-processing = 1488464765“
它不会创建任何文件。它将打印机订单直接发送到打印机

版本：

Ghostscript = GPL Ghostscript 9.18 Artifex Software
cups = 2.1.3-4
pdftopdf = cups-filters 1.8.3-2ubuntu3.1

Answer 1

您使用的是各种组件的哪些版本（CUPS，pdftpdf和Ghostscript）？

您是否检查过pdftopdf生成的中间文件以查看该PDF文件的样子？

您是否检查了gstoraster生成的CUPS栅格，看它是否正确？

我们讨论的差异到底有多大？一个像素，一英寸？请记住，这显然是一个203 dpi的设备，所以一个像素是相当多的。

鉴于管道中有3个阶段，您应该做的第一件事是尝试隔离导致问题的步骤。首先在每个阶段捕获输出; pdftopdf产生的PDF，然后是gstoraster产生的CUPS光栅文件。您可以单独检查每个问题，看看它们是否显示您的问题。如果他们不这样做，那么问题必须来自最后一步＆＃39; rastertoezpl＆＃39;而且你需要知道该代码的人。否则，您将能够确定问题是pdftopdf步骤还是gstoraster步骤。无论如何，您可以寻求具体的帮助。

PPD文件的内容最不可能在这里产生任何影响（除了指定驱动打印机所需的最终过滤器）。当然，如果没有看到原始文件，很难说，条形码可能是一种TrueType字体......

[修改

我仍然无法在您的问题中看到 Ghostscript 命令行。我无法运行CUPS而且我无法构建RasterView，因为它需要一堆我根本不具备的依赖项。

但是，我可以将它运行到TIFF。当分辨率足够低时，结果与照片相同。

您的问题是我在下面的评论中发布的错误帖子中的评论17和18中描述的问题。 PostScript（和PDF）成像模型表示，当像素的任何部分被触摸时，整个像素将被渲染到输出。

您的PDF将条形码绘制为一系列（矢量）矩形，使用的坐标和尺寸在设备的基础像素上没有精确对齐。

如果您使用Adobe Acrobat并且＆＃39;另存为＆＃39; TIFF你会看到完全相同的问题（你需要使用＆＃39;另存为＆＃39;对话框中的＆＃39;设置＆＃39;按钮将输出分辨率设置为203 dpi。

关于这个bug线程有很长的讨论，有很多可能的解决方案;

编写PostScript（或PDF），以便将坐标精确地钳制到设备网格。这可能很难，特别是如果您通过pdf2pdf运行文件。

首先绘制一个大矩形绘制条形图，然后将条形图之间的空格绘制为白色。这可能会使条形图像变得粗糙。但他们不会合并。如果打印机是热的，那么散热会降低效果。

将条形码生成为图像而不是矢量。图像不遵循像素规则的任何部分，它们使用像素的中心＆＃39;相反，它可以给予（至少稍微）更好的结果。

使用条形码字体。字体也使用不同的绘制方法，因为如果使用像素的任何部分，如果缩小字体大小，它会很快变成一系列黑色斑点。

基本上，当您使用PostScript / PDF时，您正试图将形状绘制为公差，这在像这样的低分辨率设备上是不可能的。

Linux中使用CUPS的GoDEX打印机中的条形码太宽

还有一些其他信息：

这些是每个过滤器的输出：

版本：

1 个答案: