Bug 53023 - printconf-gui should not set printcap if and lpd_bounce for remote queues
printconf-gui should not set printcap if and lpd_bounce for remote queues
Product: Red Hat Linux
Classification: Retired
Component: p2c (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-09-01 19:27 EDT by Robert K. Moniot
Modified: 2013-07-02 18:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-25 05:31:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert K. Moniot 2001-09-01 19:27:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.3-12 i586)

Description of problem:
The undesired behavior we are seeing is a blank page following printing of
a text file on a remote print queue.

We have an HP LaserJet 4000 attached to the parallel port of a Linux 7.1
server.  The server's printcap entry for the queue is as follows.
This was created using printconf-gui with no unusual options, and the EOT
box was not checked.  It works fine as a local printer for both text and
When printconf-gui is used to create printcap on clients, entries for this
remote queue are as follows:
Again, this was done with no special options and EOT not checked.  The
behavior is that text files printed from the client to this remote queue
have a blank trailer page.  PostScript does not have this problem.
The printcap(5) manpage, in the section on Bounce Queues, says ``This
[setting lpd_bounce flag] should only be done in server printcap
entries''.  There may also be a bug in lpr or lpd, since lpr_bounce and
lpd_bounce both seem to be ignored.  In fact, the only way we have found to
prevent the blank trailer pages is to remove the if option in the client
printcap entries.  But I'm not sure I have fully understood this section of
the man page.  If lpr and lpd are in fact behaving correctly, then
printconf-gui evidently should also not set if for remote queues.
I suppose it is also possible that the bug is in magicfilter, when used to
send output to a remote queue.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set up a local queue using printconf-gui.  Take the default options.
2. On a remote machine, set up a remote queue to the queue defined in step
1.   Take the default options.
3. On the remote machine, print a text test page.  On the print server,
print a text test page.

Actual Results:  On remote machine, text test page is followed by a blank
page.  On print server, it is not.

Expected Results:  Both machines should have printed the test page only,
with no following blank page.

Additional info:

We have worked around this by manually editing printcap files, but we would
like to be able to use printconf-gui.
Comment 1 Jindrich Novy 2004-11-25 05:31:33 EST
Shouldn't this be reported to the system-config-printer package? If
you have still problems using printconf-gui in recent relases, please
file a new bug for system-config-printer package.

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