Bug 696509 - The attached file is not converted properly to PDF
Summary: The attached file is not converted properly to PDF
Status: RESOLVED INVALID
Alias: None
Product: GhostPCL
Classification: Unclassified
Component: PCL interpreter (show other bugs)
Version: 9.18
Hardware: PC Windows 7
: P4 normal
Assignee: Henry Stiles
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-12 12:42 UTC by Costa
Modified: 2016-01-13 19:46 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
input file (960 bytes, text/plain)
2016-01-12 12:42 UTC, Costa
Details
photocopy of printout (14.09 KB, application/x-pdf)
2016-01-13 12:13 UTC, Costa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Costa 2016-01-12 12:42:51 UTC
Created attachment 12230 [details]
input file

The attached file doesn't convert properly to PDF, even though when printed on linux using an lpr command it prints as expected.

Is this a bug or am I missing something obvious? 

The command file that I used to generate the file is:

gpcl6win64-9.18.exe -sDEVICE=pdfwrite -sOutputFile=%1.pdf -dNOPAUSE %1.txt
Comment 1 Ken Sharp 2016-01-13 00:43:36 UTC
The file renders identically when run to the display device, this is not a problem with pdfwrite.
Comment 2 Henry Stiles 2016-01-13 07:24:01 UTC
The Artifex PCL interpreter output matches the HP Color Laserjet 400.  If you are trying to print the PCL file directly on a linux system you should use lpr -l to indicate the file is already processed.  If you are already doing that then your printer probably does not properly support PCL5.  You didn't say what result you expect.
Comment 3 Costa 2016-01-13 12:12:11 UTC
Just to give you a background on this, we are using SQR to print reports to HP Laser Jet printers on linux. These SQR reports include PCL commands. Because the SQR export to pdf sucks - it has all sorts of issues - I started to look at another solution. Using ghostpcl seems like a good idea. So I took some output files created by SQR and tried to see if they could be converted to pdf. Unfortunately the pages in the pdf don't contain all the text in the file. What's weird is that some files converted fine while the one I attached is not fine.
 
In my mind I thought that if these files are printed on a printer, then ghostpcl would work the same, it would be the equivalent of scanning a printout to pdf.

I used the lpr command without the -l switch, simply lpr -P<PrinterName> <fileName>.

The printer that I tested is a Xerox ColorQube 9303, and the driver says: Xerox Global Print Driver PCL6. Unfortunately I don't have easy access to an HP printer, all the HP printers are at a remote site.

I attached a photocopy of the Xerox printout. Please note that it was a duplex printout.

So if it's not a problem with the pdfwrite, what can be the issue?

Also, are you saying that printing to an HP Color Laserjet 400 printed the same thing that the display device shows?

Thanks
Comment 4 Costa 2016-01-13 12:13:02 UTC
Created attachment 12234 [details]
photocopy of printout
Comment 5 Costa 2016-01-13 12:14:27 UTC
Sorry, I just noticed that you marked the issue as INVALID. Why? Obviously there is a problem somewhere in ghostpcl and the software ignores content in the file.
Comment 6 Henry Stiles 2016-01-13 13:30:53 UTC
The HP printer and Artifex do not return to the left margin without a carriage return after the previous line by default.  That's consistent with the specification.  

There is a PCL command that will allow you to use different line terminations for text lines (see line termination in the PCL manual).  We probably should have a configuration option for that in ghostpcl, but we don't at this time.  I'll add it to our enhancement list.

I imagine there is a panel option on your Xerox printer where you have changed the default line termination which why you are seeing something different on Xerox.
Comment 7 Costa 2016-01-13 14:33:06 UTC
Are you saying that because there is no CR char accompanying the corresponding LF chars in the input file, then ghostpcl doesn't think it needs to go back to the left margin when it encounters an LF char?

I did convert all LFs to CRLFs in the input file and now the pdf is generated properly as I expected, so I guess the answer is yes. This is good.

But then why do the reports work on the HP printers when printed with the lpr command? None of them should work according to the spec, unless lpr inserts CR characters.
Comment 8 Henry Stiles 2016-01-13 15:01:32 UTC
(In reply to Costa from comment #7)
> Are you saying that because there is no CR char accompanying the
> corresponding LF chars in the input file, then ghostpcl doesn't think it
> needs to go back to the left margin when it encounters an LF char?
> 
> I did convert all LFs to CRLFs in the input file and now the pdf is
> generated properly as I expected, so I guess the answer is yes. This is good.
> 

Unfortunately that's not a general solution.  A linefeed can occur inside an image or other "binary" pcl object when you replace that LF with a CRLF the object will be corrupted.  Like I said you can look for the PCL line termination command in the PCL manual and figure out how to get that into the PCL stream.  The command allows you to configure text line endings.  Also, you can wait for the enhancement I promised but that's probably a ways off.

> But then why do the reports work on the HP printers when printed with the
> lpr command? None of them should work according to the spec, unless lpr
> inserts CR characters.

Your original attachment did not work on my HP printer with lpr.  It likely worked on your Xerox printer because there is a setting on the front panel to allow LF to terminate a line.  I bet if you set that option to the default you'd get the original Ghostpcl output result on the Xerox.  If you have time I'd like to verify that.  Could you check?

It's quite unusual to see PCL without Dos/Windows line endings for text, if you can fix the source generating the PCL that would be best of all.  Good luck, I'm afraid this is all the support I can provide a free user.  Thanks for using ghostpcl.
Comment 9 Costa 2016-01-13 15:32:25 UTC
Sorry, I couldn't find the setting on the printer panel. I also looked in the docs (user & sysadmin guides) but nothing came up: http://www.support.xerox.com/support/colorqube-9300-series/documentation/enca.html?operatingSystem=win7x64&fileLanguage=en.
Comment 10 Costa 2016-01-13 15:43:11 UTC
Thanks for your help!
Comment 11 Costa 2016-01-13 17:20:52 UTC
I did more debugging on linux and I just wanted to confirm that lpr doesn't add any CRs to the file, so I believe you were right when you said the printer must have been set to do the conversion automatically.
Comment 12 Costa 2016-01-13 18:52:03 UTC
Hey, just to let you know that after more debugging and printing to an actual file using lpr (I followed the instructions here: https://wiki.ubuntu.com/DebuggingPrintingProblems, 'Getting the data which would go to the printer') and using the ppd file from the actual printer, the final file includes carriage returns. Probably it is because the printer is configured as Generic text-only printer and I guess the cupsFilter "text/plain 0 textonly" adds the carriage returns. This output file renders properly in ghostpcl. Thanks again for your help.
Comment 13 Costa 2016-01-13 19:00:19 UTC
Sorry, I will bother you with one more question. Can you recommend an utility that takes a sequence of PCL commands from a file and it displays the English description of the PCL commands? I find it painful to search for the description of each command.

Thanks
Comment 14 Henry Stiles 2016-01-13 19:46:21 UTC
 git clone http://git.ghostscript.com/ghostpdl.git
 cd ghostpdl/
 ./autogen.sh 
 make gpcl6debug -j
 debugbin/gpcl6 -ZI test.txt

That should give the following:

[i][file pos=0]
Processing pjl
Exiting pjl
Selecting PDL
selected and initializing (PCL)
ESC & l 1 S
   [Simplex/Duplex Print]
ESC & l 0 O
   [Page Orientation]
ESC & k 2 S
   [Set Pitch Mode]
ESC & k 6.8 H
   [Horizontal Motion Index]
ESC & l 7.27 C
   [Vertical Motion Index]
ESC & a 0.5 L
   [Left Margin]
ESC & l 66 F
   [Text Length]
ESC & p 1 X
   [Transparent Mode]

...


HP used to make something nicer, but I haven't seen it for a while.  I use this since I always have a debug build handy.  Good luck.