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

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.

Note

You need to
log in
before you can comment on or make changes to this bug.