Red Hat Bugzilla – Bug 52032
configured printer prints extra page EVERY TIME
Last modified: 2008-05-01 11:38:00 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-2smp i686; Nav) Description of problem: I have a HP Laserjet 4 - it requires a FF in order to finalize the last page. I checked FF[] on the printer options page. printing the ASCII TEST PAGE, and any other ASCII page prints <blank page> <the page supposed to be printed> apparently it looks like the <FF> is being sent BEFORE as well as AFTER the page to print. It shoul ONLY be sent at the very end of the printing. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. configure a printer than need FF to terminate ascii printing with FF 2.print ascii text 3. Actual Results: blank page is printed before the desired output Expected Results: just the desired output Additional info: suggest checking the print filter for <FF> to see if it is printing a <FF> at the start of the print job. It should not be.
In addition to plank page for TEXT printing, there is another problem. After printing postscript pages, the following gets printed on the next page: @PJL SET MANUALFEED=OFF @PJL SET ECONOMODE=OFF @PJL SET COPIES=1 @PJL SET DENSITYY=3(MORE THAT CANNOT BE READ). The above appears on the page after the last postscript page. It appears tyo be PCL (maybe) language. The printer is configured as LaserJet 4 (ljet4 driver). This same printer was configured w/ the LaserJet 4 driver for RH 7.1, and did not have this problem. Perhaps there are differences in th e printer filter that might be causing the new problems ? -Greg
We (Red Hat) should really try to fix this before next release.
I suspect that you are double filtering. Are you printing from a client using the ljet4 driver which you have set up to print to a server using the ljet4 driver?
printer is local printer. client is same machine.
Regarding the PCL after postscripts page. I checked my options for the printer, and teh box [] convert text to postscript was checked. I unchecked it, restarted lpd, and reran some plain text and postscript tests. The postscript does not intersperse the PCL commands, but the blank page still ejects before each text job. unknown why turning off convert text to postscript would fix the PCL commands after postscript jobs...
Before upgrading to RedHat 7.2, our LaserJet 1100, configured to use the ljet4 driver, worked perfectly. However, now we're experiencing the same problem as greg@lugs.org.sg reported here at 10:17:09 on 2001-08-20, except that the PCL commands appear *BEFORE* the output rather than after and regardless of the setting of the "Convert Text to Postscript" radio button on the driver options of the printtool. Since the problem appeared first while printing mail from Netscape Messenger, I tried printing tiger.ps from the command line. Same result. Then, I downloaded and installed ghostscript-5.50 from RedHat 7.1. Same result. So, I re-installed the current version of ghostscript-6.51 and tried various settings on the options page. No change. Please help. Cheers, Tony Kocurko - Memorial University of Newfoundland
In /var/spool/lpd/lp/ljet4-62816.foo, changing this line: 'pjl' => '' to this: 'pjl' => '1' seems to do the trick. Now, where is that line being created each time /etc/rc.d/init.d/lpd restarts using /usr/share/printconf/util/printconf_backend.py? Cheers, Tony Kocurko - Memorial University of Newfoundland
I am seeing a PCL page interspersed with Postscript pages also, on an HP 1100. I had "Convert text to Postscript" initially checked too, but unchecking that option makes no difference. Additionally, the PCL page comes out before the 2nd and subsequent print job. The first postscript print job comes ok. When I print a 2nd print job the PCL page comes out before the print output. If I powercycle the printer after the first job, I do not get the PCL page with the second job. So, it seems like the PCL gets sent at the tail end of each job without a formfeed, and then goes out when the next job begins.
I tracked down the PJL problem. It seems that the xml files that define the printer characteristics, say whether or not PJL is supported.. When printtool is run, the printer's xml file is "compiled", and that goes into the printer's printcap "sd=" directory. In my case (a laser jet 4), I end up with the file /var/spool/lpd/ps/ljet4-491506.foo which had pjl= in it. after alot of grepping, I discovered that the ljet4 printer definition xml file is /usr/share/foomatic/db/source/printer/491506.xml - I editted this file, changed the line that used to read <pjl/> to instead read "<!--no pjl-->" re-ran printtool, regenerated the printcap (and associated files), and the PJL commands are no longer sent to the printer. which is to say that the file: /usr/share/foomatic/db/source/printer/491506.xml (part of "foomatic package) needs to be updated, to disable PJL for the laser jet 4 printer). As for the other 2 printers reported by mrsam@courier-mta.org,nerdboss@mail.com, someone will have to locate the respective printer defn xml file in the /usr/share/foomatic/db/source/printer/ directory, and disable PJL in them as well. -Greg
The _real_ problem is that the PJL processing was broken in printconf. This is fixed in the errata RHSA-2001:138, and if you grab the printconf, Omni, ghostscript, and foomatic packages from the updates ftp site, everything should work.