I'm not quite through trying to implement this but I thought I'd post my
status to see if I get any other feedback. This is long but hopefully will
help some other newbie in the future.
Original problem restated briefly:
We want to print directly to the print servers on 3 of our printers from
Unix. Current print server is SunOS and so has an /etc/printcap file.
These printers can handle being printed to in raw or text mode. It would
be possible to force all Unix users to point to a different print queue to
print text files but there are several reasons I'd rather just pipe all
jobs to the raw side:
1. Printing now goes through 1 queue and gatorbox does ascii to
postscript conversion. Easier for them to remember 1 queue.
2. Printing to the printers in "text" mode creates a pretty ugly
document, very little margin, large font and chops lines.
Currently, we just have the users remembering that they must use a2ps
instead of lpr to print a text file and the queues are all set to go
directly to the raw part of the printers. This is inconveinent because a)
people forget every so often b) there are scripts out there that are using
lpr by default.
What I asked about: finding a input filter to put in /etc/printcap entries
that would check a file and if it's text turn it into postscript and pass
it on to the printer.
Now onto what I found out......
I received several replies. Many just said use genscript, enscript, a2ps,
mp, mailp and a few others. That was terrific but didn't help compleletly
because I still wasn't sure how to get the filter in place. Just putting
it in /etc/printcap as an if didn't seem to work. John Ballard led me down
the correct road with the following correspondence......
" Input/output filters are handled through the printcap file
by the if/of entries for the queue. Since your printers are
all remote, the presence of the rm in the printcap file will
insure that the if/of options are ignored. A way of working
around this is to use a double queue. The first queue in the
printcap file thinks it is local and uses whatever if and of
filters you have specified in its printcap file. It then
feeds the output to the second queue which has the rm set to
the remote printer. This is, as far as I know, the only way to
run filters for a remote printer via the printcap file."
When I asked him how to set this up he pointed me to the Linux HOWTO for
printing.....
http://www.picante.com/~gtaylor/pht
He also clued me into several "magicfilter" programs that will check not
only for text but for other formats and convert them to the proper form to
send to the printer (given you have the necessary conversion programs).
Thanks bunches John!!!
Now onto what I've done......
The summary of the Linux printing howto is that you need a double queue as
John mentioned unless you want to install a package called LPRng. In which
case that lpd daemon can handle applying a filter directly to a job
destined to go directly to a remote printer.
I have been exploring both the use of the double queue and the LPRng daemons.
Here is where I'm currenlty at...
I can get the double queue to work using the magicfilter program and a
separate filter for each printer.
The filter is similar to:
#!/bin/sh
/usr/local/bin/ljet4m-filter | lpr -Peachprinternamehere
The ljet4m-filter is a config file for the magicfilter program. At first I
didn't like the way it handled text by default. It was the same ugly margin
and font that I got by printing directly to the printer in text mode. So I
tried
to get the magicfilter to pipe text through a2ps instead. The problem with
that was the output never came back to stdout so that my script could pass it
on to the lpr. I switched to enscript which allowed me to make the output
go to stdout instead of trying to go to a default printer. In that form
the double queue works.
It'd be cool if I could get the LPRng lpd daemon to work so that I would
only have to use the magicfilter but that doesn't seem to work quite right
for me right now. It's still tough to grab the printer so that enscript
knows where to send it.
I'd also like my users to be able to type: lpr -Paprinter or a2ps
-Paprinter and have it work correctly. So I'll need to check all that out.
I believe on one try that a2ps blew up trying to go through the double
queue if that's true ( I thought it'd just pass through) it'll be a bummer.
If anyone has additional thoughts I'd love to hear them. Thanks for
reading this far.
Oh yeah, one other strange problem that I'd appreciate an answer to if
anyone has a clue. On our HP 5siMX printer all postscript jobs from Unix
now default to tray3 where the legal paper is. Before they printed fine to
tray 2, normal paper. This occured when a faculty member printed a ps file
from his Mac by dragging it to a desktop printer. He then went down to add
paper and pulled the letter tray out in the middle of the job. The job
continued and just switched to tray 3 but all postscript jobs have been
stuck there since!!! Anyone else ever experienced this? And yes, we tried
to start up another job and pull out the legal tray but it never switched
back. I solved it once by putting the letter paper in tray 3 and legal in
tray 2 but all of a sudden on Mon. Mac printing had trouble getting the
paper from tray 3(kept jamming) so we had to switch back.
Thanks to the following people who sent me replies to my original query:
John Ballard
Eddy Fafard (who was kind enough to offer to help me configure a new gatorbox)
Jeff Brody
Kai O'Yang
Sean Ward
Tim Carlson
Cathy Smith
Dan Pritts
Stephen Harris
Igor Schein
Karl Vogel
Matt Reynolds
Jim Roberti
Brooke King
Rich Kulawiec
Bill Hunter
Lisa
******************************************************************
Lisa Weihl, System Administrator E-mail: lweihl@cs.bgsu.edu
Department of Computer Science Office: Hayes 225
Bowling Green State University Phone: (419) 372-0116
Bowling Green, Ohio 43403-0214 Fax: (419) 372-8061
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:39 CDT