"Dr. Bill Studenmund" wrote:

>Don't bother with this unless you put the laserwriter on LocalTalk. All of
>these filters will try to send a job to an AppleTalk printer using PAP.

----- snip

>I'd vote with leaving the thing serially connected. If you run it in pcl
>mode, all you need is a simple text filter which tells the printer that ^j
>is the new-line character, not ^m. I have a snippet of PCL code which does
>that. Or, run it in postscript mode and use enscript. I think it can be
>set up to act as a filter, where it enscripts only if the input file is
>text.

Well I gave netatalk (version from macbsd.com) a try.  First off, I have to
commend the folks who put that package together.  Compiled & installed
without a hitch.  And the man pages are, really clear and descriptive
relative to most).  Configuration (as I did it) consisted of:
	* Making sure the necessary lines were in /etc/services -- which they
	  were.

	* Having /etc/rc call rc.atalk (actually, I had it calling
rc.atalk.bsd),
	  as the last *final* action of rc.  (Good/bad?)

     * Make a printcap entry based on what lars had posted (again, the man
	  page for papd was pretty lcear as to what the filters did.)

	* Add a file, .paprc, to the printers spool directory that contained
the
	  appletalk name of the printer

	* Then 4 configuration files in /usr/local/atalk/etc.  atalk.conf
states
	  that it can usually guess the right interfaces, and it was usually
safe
	  to just leave the information out.  At multiuser boot, it complained
	  that it "couldn't open address...".  So for kicks and grins, I added
a
	  line for tty01.  No complaints after that.

	* And finally, a print-capish entry for papd.conf. Most of the
important
	  information here is conveniently included of the 'template file.

A few quick tweaks and I was able to go from single to multi-user without
any complaints, the dmesg lines just indicating that it was "starting
Appletalk daemons".

So what eventually happened when I threw the switch?  Three lines (each
having a different process number):

	ofpap[pid]: died with exit 2

Oh well.....  Then I realized, perhaps could 'interface' be synonymous with
'ethernet card interface'?

Again, oh well...

This raised another question in my mind as I was looking through the
collections of printcaps that I've collected.  When specifying a device for
lp, as in the line:

	lp=/dev/xxxx

I've been basing my entry on the device file which corresponds to where the
printer is *physically connected* (/dev/tty01).

You know, I can't find another one that does the same thing!!  Is the
device specification for lp DIFFERENT than the physical connection?

Perhaps that's why

	[stdout generating command like ls] > /dev/tty01

gets something out, but nothing else works as well.  (The above line places
assumes that the printer is connected via it's RS232 port, set to PCL4).
lp spits out something...sometimes; nothing at others, and I'm at a loss to
nail down a specific cause-effect relationship.


Oddly though, keeping the same com settings, setting the printer to
postscript mode and sending a postscript file ( such as one from
/usr/share/docs ) garners nothing more than a blinking activity LED.
Likewise with attempts with enscript.

I also noticed the 'raw' checkboxes in the booter options dialog box, and
noted in the booter manual how they could potentially cause confusion when
a printer was hooked up, as they would be interpreted as coming from
another console.  Checking the one for 'printer port' really didn't help
matters, unfortunately.

I've gotten a lot of useful advice from a number of people, which I
appreciate greatly -- guys, Thanks! --

Tell me, am I once again trying to accomplish something that 'just ain't
doable yet'?  I've had a habit of doing that in the past....

Thanks again!


Steve Revilak
revilak@umbsky.cc.umb.edu