I have a GoDEX RT700i printer (203 DPI) and I want to print barcodes in Linux (Ubuntu 16.04) The barcodes I have are in PDF format. There is a 8 digit number below the barcode.
In Windows, there is no problem with GoDEX drivers. The barcodes and the number are printed perfectly. Note: If I print the PDF from google chrome it looks fine, but if I print the PDF from Adobe Acrobat Reader, it looks like in Linux.
In Linux, when I print the barcode, the digits of the number are okay, same as Windows, and the height of the bars is okay too, but the width of every bar is bigger than the displayed in the pdf.
How can I fix this?
Here a photo of the printed barcodes
The left one has printed in Linux and the right one has printed in Windows.
There is some additional information:
For Linux I have compiled and installed the GoDEX driver for CUPS and then I have added the printer via AppSocket/HP JetDirect with the IP and Port (9100).
Then, I select the PPD file godex-rt-700i.ppd
These two lines are in the ppd file. Maybe they are related with the problem:
TTRasterizer: Type42 *cupsFilter: "application/vnd.cups-raster 50 rastertoezpl"
When I send the print order, I realized that there are 3 filters for the job:
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)
In the rastertoezpl.c file I saw that there is a function (GDXCompress) that compress the output lines for Godex printer.
I thought that maybe the compression affects somehow to the barcode and I tried to deactivate that function (CompBuffer = NULL) and recompile the driver, but that didn’t fix anything.
These are the outputs of every filter:
All files (original and intermediate outputs)
When I send the original PDF file to print, these 2 files are generated by cups in /var/spool/cups/:
d00122-001 (pdf)
c00122 (unknown)
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.69×65.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.69×65.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)
This file can be opened by rasterview program
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.69×65.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”
It doesn’t create any file. It sends the printer orders directly to the printer
Versions:
Ghostscript = GPL Ghostscript 9.18 Artifex Software cups = 2.1.3-4 pdftopdf = cups-filters 1.8.3-2ubuntu3.1
Advertisement
Answer
Which versions of the various components are you using (CUPS, pdftpdf and Ghostscript) ?
Have you checked the intermediate file produced from pdftopdf to see what that PDF file looks like ?
Have you examined the CUPS raster produced from gstoraster to see if it is correct ?
Exactly how big a difference are we discussing ? A pixel, an inch ? Bear in mind that this is apparently a 203 dpi device, so a pixel is quite a lot.
Given that there are 3 stages in the pipeline the first thing you should do is attempt to isolate which step is causing your problem. First capture the output at every stage; the PDF resulting from pdftopdf, then the CUPS raster file resulting from gstoraster. You can examine each of these individually to see if they show your problem. If they do not then the problem must arise from the final step ‘rastertoezpl’ and you’ll need someone who knows that code. Otherwise you’ll be able to decide whether the problem is the pdftopdf step, or the gstoraster step. In any event you can then ask for specific help.
Its most unlikely that the content of the PPD file has any impact here (other than specifying the final filter required to drive the printer). Of course, without seeing the original file, its hard to tell, possibly the barcode is a TrueType font…..
[edit]
Well I still can’t see a Ghostscript command line in your question. I’m not able to run CUPS and I can’t build RasterView either since it requires a bunch of dependencies I simply don’t have.
However, I can run it to TIFF. The result is the same as your photo when the resolution is low enough.
Your problem is the one described in comments 17 and 18 in the bug thread I posted in my comment below. The PostScript (and PDF) imaging model says that when any part of a pixel is touched, that whole pixel is rendered to the output.
Your PDF draws the barcodes as a series of (vector) rectanlges, using co-ordinates and sizes which are not precisely aligned on the underlying pixels of the device.
If you use Adobe Acrobat and ‘save as’ TIFF you will see exactly the same problem there (you need to set the resolution of the output to 203 dpi using the ‘Settings’ button on the ‘save as’ dialog).
There is a long discussion on the bug thread about this, there are a number of possible solutions;
- Write the PostScript (or PDF) so that the co-ordinates are precisely clamped to the device grid. This may be difficult to do, especially if you run the file through pdf2pdf.
- Draw the bars by first drawing a big rectangle, then draw the spaces between bars as white.that might make the bars ‘skinny’ but they won’t merge. If the printer is thermal then the thermal spread will reduce the effect.
- Generate the barcode as an image instead of vectors. Images don’t follow the ‘any part of pixel rule’, they use ‘centre of pixel’ instead, which may give (at least slightly) better results.
- Use a barcode font. Fonts also use a different method for drawing, because if you reduce the font size it quickly turns into a series of black blobs if you use any part of pixel.
Basically, you are trying to draw shapes to a tolerance which simply isn’t possible on a low-resolution device like this, when using PostScript/PDF.