Ghostpcl head (r3509+8645) does read the attached file correctly. An HP LaserJet 4100 prints an invoice; Ghostpcl generates a page with a single letter on it. The command line I'm using for testing: main/obj/pcl6 ./test.pcl The file, test.tif, shows a scan of the LaserJet output.
Created attachment 3946 [details] test.pcl
Created attachment 3947 [details] test.tif
It looks like the file was not properly generated: It begins as follows: <FINE><WHO:WRAP><TOFAXNUM:01225301201><UNIQUEID:007:R100100><TONAME:BN6973/R100100/WrapIn><NOCOVER>%-12345X@PJL SET PAGEPROTECT=AUTO^@PJL SET ECONOMODE=OFF^@PJL SET RESOLUTION=600^@PJL ENTER LANGUAGE=PCL... The bracketed text is not pcl, the PJL is not properly delimited with a LF, as specified in the pjl manual. If the offending start is removed the file prints as expected. Lowering priority to P3 to reflect the problem requires emulating behavior that is contrary to the pcl and pjl specification.
The attached test.pcl file does not begin as you state in comment #3: marcos@macbookpro:[72]% more test.pcl ESC%-12345X@PJL SET PAGEPROTECT=AUTO^@PJL SET ECONOMODE=OFF^@PJL SET RESOLUTION= 600^@PJL ENTER LANGUAGE=PCL^ESCEESC*t600RESC&u600DESC*r0FESC&l0OESC&l0SESC&l1H ESC&l26a8c1EESC*p0x0YESC*c0t5594x8201YESC&l1XESC*b0M^MESC(19UESC(s16901t0b0s10v1 PESC*p3678XESC*p5766Y ESC(9UESC(s4148t3b0s12v1PESC)6JESC)s4148t3b0s12v1PESC*p233 0XESC*p184Y ESC(9UESC(s4148t0b0s8v1PESC)6JESC)s4148t0b0s8v1PESC*p2330XESC*p272Y ESC(9UESC(s4148t3b0s12v1PESC)6JESC)s4148t3b0s12v1PESC*p324XESC*p384Y ESC*p624X ESC(9UESC(s4148t3b0s10v1PESC)6JESC)s4148t3b0s10v1PESC*p2330XESC*p489Y ESC*p2330X ESC*p589Y ESC*p324XESC*p689YESC%1BSP1; PW ;TR0 ; WU0; PW0.010,1; SP1; PU1878,100 I agree that it doesn't have linefeeds between the PJL commands and I can get the file to process correctly if I remove the PJL, but I think we should make an effort to emulate the HP behaviour.
I downloaded again and I didn't get data before the PJL, that is very odd, I can't imagine where that data came from. I agree we should look at emulating HP's accepting PJL commands without LF termination.
After a few experiments it appears the pjl parser behaves very differently than documented in the PJL technical reference manual. It would probably be a major project to reverse engineer the exact behavior of the HP PJL interpreter on a particular printer and, of course, there is no guarantee that would work on all devices. This file demonstrates character other than '\n' may delimit a line and pcl control codes can begin without any intervening whitespace after pjl. We don't expect a solution to this problem any time in the near future. Our current pjl implementation is compliant with the documented parsing in the pjl reference manual.
Changing customer bugs that have been resolved more than a year ago to closed.