[comp.laser-printers] TI 2115 laser & multiple Unix print queues

tim@nottingham-institute-of-hearing-research.mrc.ac.UK (Tim Folkard) (07/27/89)

Does anyone out there have any experience of the TI2115 in a 
Unix environment ???

We have three print queues (postscript, laserjet & HPGL) all 
aimed at the printer and have difficulty switching between the 
different emulations. The solution we have usually works, but 
involves all sorts of messy delays, and still manages to 'lose'
output occasionally.

If anyone else has solved this problem, or even encountered it, 
I would be keen to exchange ideas. 

Regards,
  Tim Folkard
                ( JANET: tim@uk.ac.mrc.not-ihr
                ( Post:  MRC Institute of Hearing Research
                (        Nottingham University,    NG7 2RD
                (        England
                ( Tel:   0602-223431    Fax:   0602-423710

perl@step.UUCP (Robert Perlberg) (08/28/89)

There are a number of ways of dealing with this.  In general, I have
found that multiple print queues are generally a bad idea.  However, if
you want to go with multiple print queues, my advise would be to have
only one queue that actually writes to the printer.  The other queues
would then massage the data and relay it to the "real" printer queue.
This tends to create problems in that after the job has been
resubmitted it no longer belongs to the original submitter and cannot
be removed from the queue.  It also makes it hard to control the
sequencing of jobs and users get confused as to which queue their jobs
are in.

The best way I have found is to have just one queue and communicate to
that queue in some way how you want it to process the job.  If you are
using the System V lp spooler, this has already been built in.  You can
make up your own print filter options and pass them to lp with the -o
option.  If you are not using such a spooler, you can create a front
end shell script or program for lpr which accepts options which tell it
how to massage the data before feeding it to lpr.  That way the job
belongs to the original user, and the massaging need not be done by the
print spooler.  If you want the print spooler to do the massaging, you
can design the lpr front end to just prepend a control line to the file
which the print filter can read to determine how to process the rest of
the file.  Also, instead of having a single front end with options, you
might want to have a number of front ends, each of which does a
different kind of processing.  If you are using the Sun (BSD) lpr
spooler, there is another, albeit dirtier, way of doing it.  You could
use the lpr options which control which filter the spooler will use for
purposes other than those for which they were intended.  For example,
you might use the FORTRAN filter option to invoke your HPGL filter, and
so on.

We are currently using the front end with options technique and we find
it to provide a high degree of flexibility, to the extent of even being
able to use it to redirect print jobs to a different printer if the
target printer is down, and supporting remote printers via uux.

Robert Perlberg
Dean Witter Reynolds Inc., New York
phri!{dasys1 | philabs | mancol}!step!perl
	-- "I am not a language ... I am a free man!"