Bug 66133 - No way to print files either in an order or contiguously
No way to print files either in an order or contiguously
Product: Red Hat Linux
Classification: Retired
Component: LPRng (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Tim Waugh
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-06-04 23:55 EDT by kop
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-08 08:14:46 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 kop 2002-06-04 23:55:42 EDT
Description of Problem:

I've sets of several postscript files I need to print, in order
with no other jobs inserted into the set.  A printer has been
dedicated to this.  A single set consists of some postsript files,
each of which must be printed in it's given position relative
to the others in the set.

lpr -B doesn't work.  Nothing comes out.  There's nothing in
the /var/spool/lpd/<printer>status.<printer> file.  Sometimes there's
a delay with a lot of cpu consumption and sometimes there's
what seems to be an even longer delay with no cpu used.
lpr -B would solve my problem.  The files in the set would
be in a guarenteed order and another job could not be inserted
into the middle of a set.

The printer works fine when individual jobs are printed, but
(apparently) because the files are of different sizes,
they (apparently) don't make it into the queue until after
varying amounts of background processing and delay.  So,
I can't order the files.

Because the printer is dedicated to this application, I tried
using a lock, to ensure that only one "set" of files is queued
at a time.  But this means that I have to order the files within
the sets, and I can't do this because...

lpr -G dosen't work.  It gives me a usage message.  If it worked,
all the processing that normally occurs in the background would
be in the forground, and I could be sure that the order in which
I submit the jobs is the order in which they are inserted into
the queue.  (Yes?)

I thought of using the class, lpr -C, to prioritize the print jobs.
But that means that I can
have only 26 jobs in the queue before the queue wraps and things
break.  (Plus the hassle of having to keep state laying around.)

There doesn't seem to be a workaround.  (If I ever do get it working,
I'd like to use custom banners to inject some PCL into the
printer's data stream, varying per file.  It would be good if a
solution would accomidate this.  But really, I want lpr -B to work.)

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


I'm using RedHat 7.2 with LPRng 3.7.4 (redhat release 28),
which uses magicfilter as the input filter and am printing
over the network to a HP 4100-tn laser printer.  The printer
driver is "lj5gray".

How Reproducible:


Steps to Reproduce:

Try something like:

echo cover1 | lpr 
lpr small.ps
lpr big.ps
echo cover2 | lpr
lpr small.ps
lpr big.ps
echo cover3 | lpr
lpr small.ps
lpr big.ps
echo cover4 | lpr
lpr small.ps
lpr big.ps

Either use big files or a slow system to really see the impact.

Actual Results:

Print jobs don't come out in the order submitted.

Expected Results:

Print jobs should come out in the order submitted.

Additional Information:

One of the things that's going on here is I'm trying to use
colored paper from another tray in specific places to help
in separating the print output.

This seems like a very basic requirement for a printing subsystem.
Comment 1 Tim Waugh 2002-06-19 06:08:21 EDT
Confirmed, and it still happens in LPRng 3.8.x.
Comment 2 Tim Waugh 2004-12-08 08:14:46 EST
We use the CUPS spooler now; closing.

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