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.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)
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.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"
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
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.
Related
I've a document in Fraktur font and performed an OCR with tesseract (language is deu-frak). It took me about 10 days (24h a day) to convert these 23 issues (with each about 400 pages).
The result is a searchable PDF with the original image embedded and the invisible text on top:
Now, I've removed the image with Master PDF Editor and turned the text type from "invisible" to "Full text". Now it turned out, that some words weren't recognized by tesseract as such, so each letter is positioned separately:
Notice, that "kommen" was recognized as word but "fruchtbaren" only as a sequence of characters. This makes it impossible to find "fruchtbaren" with the textsearch and when changing the font-size the letters overlap or create ugly gaps.
I'm using Linux and look for a command-line tool which allows to script all 23 PDF documents.
Is it possible to connect textboxes with a minimum distance or even connecting one line would be great?
Thanks.
Probably not what you want to hear, but I'd go back and experiment with pre-processing, Tesseract parameters, etc on a small representative sample until you get the initial OCR as good as possible (including word segmentation) and then re-run the OCR with your new settings. If you still find that you need some type of post-processing, I'd, again, build and refine the entire pipeline on a small sample before running your full dataset.
On the surface, it looks like something Tesseract could do a better job at, provided you're giving it clean images with enough scan resolution.
What I need to be able to do is to rotate a PDF clockwise or counter clockwise either programmatically or from the CLI.
I have spent considerable time researching and attempting to rotate PDFs with GhostScript (as GS is already installed for other reasons) to no avail, nothing seems result in any rotation.
I have looked into using pdftk but it requires java libraries, and I would rather not have java installed on the system.
We've even looked at modifying the PDF file ourselves, and we have had some success with this, but we haven't come across a reliable method that works for all PDFs.
So my #1 preference would be to achieve this with existing resources on the system.
My #2 preference would be to do a little modification to the existing system as possible to achieve this.
The server in question is using Linux (OpenSuse 11) with PHP 5.2 and I have Ghostscript 9.0 installed.
Any advice would be much appreciated.
You can use pdfpages LaTeX package
\documentclass{article}
\usepackage{pdfpages}
\begin{document}
\includepdf[angle=45]{document.pdf}
\end{document}
The LaTeX document above, compiled via pdflatex, produces a document rotated 45 degrees.
There are also tools (wrappers of pdfpages) like pdfjam that can be used directly from command line:
$ pdfjam --suffix rotated45 --angle 45 --fitpaper true document.pdf
There is a way to do this with ImageMagick, if that's available to you.
Example:
$ convert originalfile.pdf -rotate <cw_angle_degrees> newfile.pdf
Note, however, that since this is a raster-based rotation, there will (generally) be a noticeable loss of quality AND increase in filesize.
You haven't said how you are trying to do this with Ghostscript, but if you want to use the pdfwrite device you will need to set /AutoRotatePages=/None or it will rotate the final page so that the majorty of any real text is horizontal.
I'm trying to use my RZ400 for the first time. I have placed the RFID tags and the ribbon, calibrated the media and sent the
^XA
^RS8
^FO50,50^A0N,65^FDHex Pattern 1^FS
^RFW,H^FD112233445566778899AABBCC^FS
^XZ
instructions from the programming manual and a RFID tag is printed. The problem is that the NEXT tag is the one that gets encoded.
The tags are SMARTRAC 292-2 Belt and the dimensions are 3x0.625 inches. This is a supported tag according to the vendor.
Thanks.
I believe the issue here is the ordering of your ZPL commands.
The ^FO line will print a label with "Hex Pattern 1". However, after printing, it will advance a tag. Try the following code and see if the tag is encoded and then printed on:
^XA
^RS8
^RFW,H^FD112233445566778899AABBCC^FS
^FO50,50^A0N,65^FDHex Pattern 1^FS
^XZ
Hopefully this will solve the issue.
This problem happened to me with the same printer, but printing from Label Matrix software. I was using a Confidex Casey that worked out of the box, but then switched to a Confidex Carrier Pro and the problem started to happen.
This happens because the printer is not properly calibrated with the Tag you are using.
You need to follow the instructions on the Zebra RZ400 Inlay Placement Guidelines for calibrating your Tag. There are three things you can do:
Run the RFID Calibrate command in the front panel of the printer. Try again.
If it's still tagging the next one, then run the command again, BUT use the option RESTORE instead to revert the previous calibration. Try again.
If it STILL doesn't works, you will need to manually calibrate the Pitch value using SetGetDo commands against the printer using the guide in the manual I linked.
Good luck.
I'm using the Domestic shipping label api in usps to generate domestic shipping labels in pdf format. I managed to crop the top section of the pdf file which is the label needed by the usps and Ignored the bottom section which is the receipt which is not needed in shipping.
I use Ghostscript /Cropbox to crop the section that I only want which is successful but when I try to print the cropped pdf file in linux cups I get the whole uncropped pdf printed instead of the cropped pdf file. Why is it still printing the whole file instead of just printing the cropped section?.
Here's the script I'm using to crop the usps Shipping label.
gs -o cropped.pdf -sDEVICE=pdfwrite -c "[/CropBox [50.4 460.5 484.4 750.5] /PAGES pdfmark" -f uncropped.pdf
Then to change its orientation to portrait i use pdftk
pdftk cropped.pdf cat 1L output cropped_portrait.pdf
To print it in linux cups I'm using the command.
lp cropped_portrait.pdf
But when i print it it is printing the uncropped.pdf file instead of cropped_portrait.pdf.
Why is it doing that? I even deleted uncropped.pdf and tried printing again but it still prints uncropped.pdf.
Here's the two files the uncropped and cropped usps shipping labels.
Uncropped PDF file
Cropped PDF file
Hope you can help me on this one,
Thank you
Presumably the reduced PDF file displays correctly, so there is no problem with Ghostscript producing the PDF file.
As to why the printing process doesn't respect the CropBox, there is no reason really why it should. There are many Boxes in PDF and no real way for a print application to know which one you want to use. As a result printing applications often default to the MediaBox, which you haven't altered (Note that altering the CropBox doesn't change the content of the PDF file, just what is displayed).
Now, if your CUPS chain is using Ghostscript to render the PDF file, or convert it to PostScript, then this can be solved, you need to add -dUseCropBox to the command line. However I'm not a CUPS expert so I can't tell you how to do that. If CUPS isn't using Ghostscript then its probably still possible to instruct whatever is doing the conversion to use the CropBox, but you're going to have to find out what application is involved and alter the command appropriately for that application.
I have a large collection of half-page sized PDF cut-sheets that are held in a folder on my Linux server. A user to the site will want to create a booklet from a subset of these. The booklet will be bound therefore the even pages of the collection will want more margin on the right side and the odd pages will want more margin on the left side. There can be up to 200 pages in a collection out of a universe of 500 pages so I don't want to regenerate each page to set the margin of it. It would take too much of the servers time to run the content through the DOMPDF. Just building the document using PDFTK is fast.
I'd like to merge the document with PDFTK from a centered PDF file and add the appropriate margin for the odd or even page.
If not PDFTK then is there another tool that might do the job?
If you use ubuntu, you can install pdfcrop:
sudo apt-get install -y pdfcrop
Despite its name, pdfcrop has the option to add margins:
pdfcrop --margin '29 0 29 0' input.pdf output.pdf
(Note: the unit is bp. 72 bp = 1 inch. 29 bp is approximately 1 cm.)
Then, use pdfjam to do the offset trick for the right and left pages.
pdfjam --twoside --offset '1cm 0cm' file.pdf
Note: pdfcrop does have problems with some pdf files. (!!! Error: Ghostscript exited with error code 139!).
If you are still interested in this, you should have a look at pdfjam which allows you to offset and clip pdfs. With respect to your particular question you might do something like
pdfjam --twoside --offset '2cm 0cm' file.pdf
This shifts the even pages 2cm to the right and the odd one to the left.
pdfjam is a front end to the pdfpages package of pdflatex.
Even if it is a bit late, but it might help someone. In response to #ElkeSpaak comment, it's the package texlive-extra-utils:
dpkg-query -S /usr/bin/pdfcrop
texlive-extra-utils: /usr/bin/pdfcrop