At 9:21 Uhr +0100 10.02.1998, Sean Sweda wrote:
>On Mon, 09 Feb 1998 23:28:02 +0100,
>Hauke Fath rearranged the electrons to say:
>>
>>This printer - is it attached to your box via serial I/O, or is it a
>>network printer? I've spent days wading through the undocumented "features"
>>of the Berkeley line printer suite, and one of the goodies is that
>>filtering only works for _local_ printers. If you print remotely, lpd will
>>happily ignore all your neat filters and never say a word...
>
>Yep.  It's remote.  Thanks for letting me know about this, didn't see
>a word about it in the printcap or lpd man pages.  I wanted to be able
>to print plain text and postscript files to the same queue, w/o having
>to remember to use enscript with plain text.  Oh well...

Well, there's a trick... As it happens, just yesterday i hacked my printcap
at work to add a psnup filter. You have to have a two-stage queue system:
the first stage "pretends" to print to a local device (i.e. you provide
:lp=...:, but not :lr=...:). Therefore its filter is used and can inject
its stuff into the "raw" queue that feeds it to the remote printer. The lpr
setup that comes with ghostscript does it this way.

I'll send you my /etc/printcap from work tomorrow; I print via Berkeley
line printer protocol to an Apple LaserWriter 16/600, but wrt. filter setup
that should make no difference.

>>Another one is
>>that lpd wants to open the dummy device that you provide in the :lp=...:
>>line _exclusively_ and fails silently if that doesn't succeed.
>
>My dummy device is just another /dev/null mknod'ed in the spool
>directory.  I picked this trick up a while back when using netatalk
>on SunOS.

Hey, that's neat! Of course, you can mknod anywhere you want; no need to
clutter /dev...

>Yeah, found Bonnie while doing web searches (lmbench wouldn't compile
>for me either, but I stopped fooling with it when I found Bonnie).  To
>eliminate the problem you're talking about above, I'm running it while
>in single-user, on my /tmp partition.  I don't really believe the
>numbers its spitting out at me in raw terms, but at least I can
>compare them against each other.  I'm going to fool around with
>increasing the buffer cache as well...

Even single user doesn't save your CPU from losing clock interrupts while
being flooded with disk interupts.

	hauke



--
"It's never straight up and down"     (DEVO)