Bug 52032 - configured printer prints extra page EVERY TIME
Summary: configured printer prints extra page EVERY TIME
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: printconf   
(Show other bugs)
Version: roswell
Hardware: i386 Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-19 09:57 UTC by greg hosler
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-30 14:53:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description greg hosler 2001-08-19 09:57:52 UTC
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:

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

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.

Comment 1 greg hosler 2001-08-20 14:17:09 UTC
In addition to plank page for TEXT printing, there is another problem.

After printing postscript pages, the following gets printed on the next page:


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 ?


Comment 2 Glen Foster 2001-08-20 19:22:27 UTC
We (Red Hat) should really try to fix this before next release.

Comment 3 Crutcher Dunnavant 2001-08-22 20:58:07 UTC
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?

Comment 4 greg hosler 2001-08-22 23:25:40 UTC
printer is local printer. client is same machine.

Comment 5 greg hosler 2001-08-23 13:26:22 UTC
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...

Comment 6 Tony Kocurko 2001-10-26 12:48:27 UTC
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.

Tony Kocurko - Memorial University of Newfoundland

Comment 7 Tony Kocurko 2001-10-26 14:26:13 UTC
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 

Tony Kocurko - Memorial University of Newfoundland

Comment 8 Sam Varshavchik 2001-10-29 13:08:06 UTC
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.

Comment 9 greg hosler 2001-10-30 14:53:47 UTC
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,
will have to locate the respective printer defn xml file in the
directory, and disable PJL in them as well.



Comment 10 Crutcher Dunnavant 2001-11-01 19:55:16 UTC
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

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