Linux 中带有 CUPS 的 GoDEX 打印机中的条码太宽
Barcodes too wide in a GoDEX printer with CUPS in Linux
我有一台 GoDEX RT700i 打印机 (203 DPI)，我想在 Linux (Ubuntu 16.04) 中打印条码
我的条形码是 PDF 格式。条形码下方有一个8位数字。
在Windows中，GoDEX驱动没有问题。条形码和数字打印完美。
注意：如果我从 google chrome 打印 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)。
然后，我selectPPD文件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/:
中的 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= time-at-creation=1488464765 time-at-processing=1488464765" /var/spool/cups/d00122- 001 > 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= time-at-creation=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= time-at-creation=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
您使用的是哪些版本的各种组件（CUPS、pdftpdf 和 Ghostscript）？
您是否检查过从 pdftopdf 生成的中间文件以查看该 PDF 文件的外观？
您检查过 gstoraster 生成的 CUPS 栅格是否正确吗？
我们讨论的究竟有多大差异？一个像素，一英寸？请记住，这显然是一个 203 dpi 设备，因此一个像素相当多。
鉴于管道中有 3 个阶段，您应该做的第一件事是尝试找出导致问题的步骤。首先捕获每个阶段的输出；从 pdftopdf 生成的 PDF，然后是从 gstoraster 生成的 CUPS 光栅文件。您可以单独检查每一个，看看它们是否显示您的问题。如果他们不这样做，那么问题一定来自最后一步 'rastertoezpl' 并且您需要知道该代码的人。否则，您将能够确定问题是出在 pdftopdf 步骤还是 gstoraster 步骤。在任何情况下，您都可以寻求具体帮助。
PPD 文件的内容不太可能对此处产生任何影响（除了指定驱动打印机所需的最终过滤器之外）。当然，没有看到原文件，很难判断，可能条码是TrueType字体.....
[编辑]
好吧，我在您的问题中仍然看不到 Ghostscript 命令行。我无法 运行 CUPS，我也无法构建 RasterView，因为它需要一堆我根本没有的依赖项。
不过，我可以运行把它转成 TIFF。当分辨率足够低时，结果与您的照片相同。
你的问题是我在下面的评论中发布的错误线程中评论 17 和 18 中描述的问题。 PostScript（和 PDF）成像模型表示，当触摸 像素的任何部分 时，整个像素都会渲染到输出。
您的 PDF 将条形码绘制为一系列（矢量）矩形，使用的坐标和尺寸在设备的底层像素上未精确对齐。
如果您使用 Adobe Acrobat 和 'save as' TIFF，您会看到完全相同的问题（您需要使用 'Settings' 按钮将输出分辨率设置为 203 dpi 'save as' 对话）。
bug 线程上对此进行了长时间的讨论，有许多可能的解决方案；
- 编写 PostScript（或 PDF），使坐标精确地夹在设备网格上。这可能很难做到，尤其是如果您通过 pdf2pdf 运行 文件。
- 通过首先绘制一个大矩形来绘制条形图，然后绘制条形图之间的空间，因为 white.that 可能会使条形图 'skinny' 但它们不会合并。如果打印机是热打印机，则热扩散会降低效果。
- 将条形码生成为图像而不是矢量。图片不遵循 'any part of pixel rule'，而是使用 'centre of pixel'，这可能会（至少稍微）提供更好的结果。
- 使用条形码字体。字体也使用不同的绘制方法，因为如果你缩小字体大小，如果你使用像素的任何部分，它很快就会变成一系列黑色斑点。
基本上，当使用 PostScript/PDF.
时，您正在尝试将形状绘制到公差范围内，这在像这样的低分辨率设备上根本不可能实现。
我有一台 GoDEX RT700i 打印机 (203 DPI)，我想在 Linux (Ubuntu 16.04) 中打印条码 我的条形码是 PDF 格式。条形码下方有一个8位数字。
在Windows中，GoDEX驱动没有问题。条形码和数字打印完美。 注意：如果我从 google chrome 打印 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)。
然后，我selectPPD文件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/:
中的 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= time-at-creation=1488464765 time-at-processing=1488464765" /var/spool/cups/d00122- 001 > 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= time-at-creation=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= time-at-creation=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
您使用的是哪些版本的各种组件（CUPS、pdftpdf 和 Ghostscript）？
您是否检查过从 pdftopdf 生成的中间文件以查看该 PDF 文件的外观？
您检查过 gstoraster 生成的 CUPS 栅格是否正确吗？
我们讨论的究竟有多大差异？一个像素，一英寸？请记住，这显然是一个 203 dpi 设备，因此一个像素相当多。
鉴于管道中有 3 个阶段，您应该做的第一件事是尝试找出导致问题的步骤。首先捕获每个阶段的输出；从 pdftopdf 生成的 PDF，然后是从 gstoraster 生成的 CUPS 光栅文件。您可以单独检查每一个，看看它们是否显示您的问题。如果他们不这样做，那么问题一定来自最后一步 'rastertoezpl' 并且您需要知道该代码的人。否则，您将能够确定问题是出在 pdftopdf 步骤还是 gstoraster 步骤。在任何情况下，您都可以寻求具体帮助。
PPD 文件的内容不太可能对此处产生任何影响（除了指定驱动打印机所需的最终过滤器之外）。当然，没有看到原文件，很难判断，可能条码是TrueType字体.....
[编辑]
好吧，我在您的问题中仍然看不到 Ghostscript 命令行。我无法 运行 CUPS，我也无法构建 RasterView，因为它需要一堆我根本没有的依赖项。
不过，我可以运行把它转成 TIFF。当分辨率足够低时，结果与您的照片相同。
你的问题是我在下面的评论中发布的错误线程中评论 17 和 18 中描述的问题。 PostScript（和 PDF）成像模型表示，当触摸 像素的任何部分 时，整个像素都会渲染到输出。
您的 PDF 将条形码绘制为一系列（矢量）矩形，使用的坐标和尺寸在设备的底层像素上未精确对齐。
如果您使用 Adobe Acrobat 和 'save as' TIFF，您会看到完全相同的问题（您需要使用 'Settings' 按钮将输出分辨率设置为 203 dpi 'save as' 对话）。
bug 线程上对此进行了长时间的讨论，有许多可能的解决方案；
- 编写 PostScript（或 PDF），使坐标精确地夹在设备网格上。这可能很难做到，尤其是如果您通过 pdf2pdf 运行 文件。
- 通过首先绘制一个大矩形来绘制条形图，然后绘制条形图之间的空间，因为 white.that 可能会使条形图 'skinny' 但它们不会合并。如果打印机是热打印机，则热扩散会降低效果。
- 将条形码生成为图像而不是矢量。图片不遵循 'any part of pixel rule'，而是使用 'centre of pixel'，这可能会（至少稍微）提供更好的结果。
- 使用条形码字体。字体也使用不同的绘制方法，因为如果你缩小字体大小，如果你使用像素的任何部分，它很快就会变成一系列黑色斑点。
基本上，当使用 PostScript/PDF.
时，您正在尝试将形状绘制到公差范围内，这在像这样的低分辨率设备上根本不可能实现。