Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 66133 - No way to print files either in an order or contiguously
Summary: No way to print files either in an order or contiguously
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng
Version: 7.2
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-05 03:55 UTC by Karl O. Pinc
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-12-08 13:14:46 UTC


Attachments (Terms of Use)

Description Karl O. Pinc 2002-06-05 03:55:42 UTC
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):

LPRng-3.7.4-28

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:

Always.


Steps to Reproduce:

Try something like:

#!/bin/bash
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 10:08:21 UTC
Confirmed, and it still happens in LPRng 3.8.x.

Comment 2 Tim Waugh 2004-12-08 13:14:46 UTC
We use the CUPS spooler now; closing.


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