Samba/Printing

[Mac]

Chuck,


>The behavior I see is:
>1) Print ok from Unix, banner or no as config'd, ejects page, end of job.
>2) Print from NT (4sp3), using proper printer drivers, gets an extra page at the end, i.e., 
>    prints the job, ejects last page, then ejects another blank sheet.
>
>Now, I can stop the last page waste by adding a :sf:  suppress form/feed to printcap,
>but then printing from Unix won't eject the page, must hit FF on printer to get the page,


This is 100% typical of UNIX and Desktop printing.  It's also understandable.

NT (and other Desktop O/Ses) all send completely formatted data in their printjobs,
including font, layout, and final Form Feed.

UNIX printing has always had the philosophy of adding the final form feed to allow
users to send _un_formated text files to printers, and not have to worry about
adding Form Freeds manually.

The way we solve this is to have two printer queues.  One is the normal UNIX printer queue.
text jobs are sent here by UNIX users, and they have a form feed added.

The other is a 'raw' or 'pass-through' queue which is specifically set up to pass print
jobs through 100% untouched.  In our case this has :sf: :sh: and :mx#0: and jobs are sent
to the 'raw' port on the remote (HPJetDirect) box to ensure that all printjobs get
through unaltered.

Then you arrange that Samba uses the 'pass-through' queue, and UNIX users continue to 
use the original queue.

The other luxury we have (and it definately won't be an option for everyone) is to have
one LaserJet dedicated to text jobs, and a bigger one exclusively for PCL and PostScript
work.


One final word of warning.  If you're using HP JetDirect to do remote printing,
then be aware that JetDirects can only handle a single TCP/IP connection at a time.
So, if a job's being printed, then a queue request (lpq) will hang until the printjob
has been transfered.  Likewise, with the two queue scenario I've outlined above,
a printjob being sent through one queue to the JetDirect will block the other queue
(even though they're on the same UNIX box).  As a worst case, if one queue (say the UNIX
text queue) is full of jobs, and keeps getting more in, then the 'pass-through'
queue will not be able to send any jobs.  There is a way round this too which involves
a tiny 'FF' filter, but I've not tried it, and it's not worth the effort in our
circumstances.



                               Mac
          Assistant Systems Adminstrator @nibsc.ac.uk
                        dmccann at nibsc.ac.uk
   Work: +44 1707 654753 x 285     Everything else: +44 956 237670 (anytime)