Subject: Re: using netatalk's psf filter
To: Sean Sweda <sweda@netcommandos.com>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
List: port-mac68k
Date: 02/09/1998 23:28:02
At 0:54 Uhr +0100 09.02.1998, Sean Sweda wrote:
>Has anyone had success using the psf filter that comes with the
>netatalk package with normal lpd printing?  I've tried to list
>it as a filter in order to allow printing of non-postscript files
>to a postscript printer, but it never seems to work.  Here's
>an example of my printcap file:
>
>laser|Advantage Laser Printer:\
>        :sd=/var/spool/lpd/laser:\
>        :lp=/var/spool/lpd/laser/null:\
>        :lf=/var/log/lpd/laser:\
>        :of=/usr/local/atalk/etc/filters/ofpsf:\
>        :if=/usr/local/atalk/etc/filters/ifpsf:\
>        :tf=/usr/local/atalk/etc/filters/tfpsf:\
>        :rm=lp:rp=lp_cr:mx#0:
>
>Piping a file through psf and then through lpr works fine, but
>normal printing does not seem to invoke psf.

Hum.

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... 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.

The NetBSD "documentation" sucks big solid rocks on that ground; I have
found the FreeBSD handbook (html) and the Linux printing-howto valuable
sources of information.

I wish you luck.  ;)

>Also, on an unrelated note, is there a disk performance benchmarking
>tool that will compile under netbsd/mac68k?  I want to compare
>the performance of different kernels (ncrscsi vs. sbc drivers)
>and need something that will extensively test reading and writing.

I seem to recall I ran "bonnie" years ago. "lmbench" wouldn't compile, then.
Keep in mind that heavily exercising your disks will slow down the system
clock considerably and take the "results" with a grain of salt or two...

	hauke



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