0

I am using ghostpcl-9.18-win64. This is the script that I used to generate the pdf file:

gpcl6win64-9.18.exe -sDEVICE=pdfwrite -sOutputFile=%1.pdf -dNOPAUSE %1.txt

The file to test can be found here and the result of running ghostpcl can be found here.

If you take a look at the pdf file it contains only a page (there should be 2) and some of the text is missing. Why is that? I always pictured in my mind that ghostpcl would produce a pdf identical with a printout. Am I missing something, parameters perhaps?

As a matter of fact, when I used the lpr command to print the file on RHEL it printed exactly what I expected. I wonder how reliable is the ghostpcl tool in converting pcl files to PDF. And if it's not that reliable, a broader question is: is there another tool to do it? I am interested mainly in the linux version.

The txt file is based on a file generated using SQR.

Thanks

boggy
  • 3,674
  • 3
  • 33
  • 56
  • OK Firstly the file you point at is apparently just a text file, not real PCL. Secondly, if you run it through gpcl6win32.exe using the display device then you will see exactly the same output. So its nothing to do with creating a PDF file from the input. I am not a PCL expert and I do not have a PCL printer to try this on. If you believe that the output is incorrect then you should open a bug report (but not against the pdfwrite device) and someone who understands PCL will tell you why this is happening. My guess is its a difference between PCL implementations, they are not very standard. – KenS Jan 13 '16 at 08:20
  • Actually it does contain PCL, so you really will have to get someone who understands it to look at the file. – KenS Jan 13 '16 at 08:21

2 Answers2

0

In fact the OP did raise a bug report (but didn't mention it here):

http://bugs.ghostscript.com/show_bug.cgi?id=696509

The opinion of our PCL maintainer is that the output is correct, inasmuch as it matches at least one HP printer. See the URL above for slightly more details.

KenS
  • 30,202
  • 3
  • 34
  • 51
  • Yes, I confirm I created the bug report. I was going to update my post today but you were ahead of me. Thank you. – boggy Jan 13 '16 at 19:41
0

Based on the discussion on the bug thread, the input file is invalid because it should have had CRLFs instead of LFs only.

If I convert the LFs to CRLFs then my input file is converted as expected to PDF. However, converting LFs to CRLFs is not a general solution. According to support LFs can be used for images. In that case converting such an LF to CRLF could break the image.

It seems that there is one thing I was wrong about on the bug thread, in our system, lpr includes carriage returns as well in the final file that gets sent to the printer. I followed the instructions here: https://wiki.ubuntu.com/DebuggingPrintingProblems, and the instructions in the 'Getting the data which would go to the printer' section to print to a file and the file includes Carriage returns.

boggy
  • 3,674
  • 3
  • 33
  • 56