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
<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):
Steps to Reproduce:
1. configure a printer than need FF to terminate ascii printing with FF
2.print ascii text
Actual Results: blank page is printed before the desired output
Expected Results: just the desired output
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 ?
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 firstname.lastname@example.org 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.
Tony Kocurko - Memorial University of Newfoundland
In /var/spool/lpd/lp/ljet4-62816.foo, changing this line:
'pjl' => ''
'pjl' => '1'
seems to do the trick. Now, where is that line being created each
time /etc/rc.d/init.d/lpd restarts using
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
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
I editted this file, changed the line that used to read <pjl/> to instead read
re-ran printtool, regenerated the printcap (and associated files), and the PJL
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 email@example.com,firstname.lastname@example.org,
will have to locate the respective printer defn xml file in the
directory, and disable PJL in them as well.
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