Subject: Re: Measured progress on the laserwriter front
To: Steve Revilak <revilak@umbsky.cc.umb.edu>
From: Dr. Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 01/09/1999 13:43:07
On Sat, 9 Jan 1999, Steve Revilak wrote:

> "Dr. Bill Studenmund" wrote:
> 
> Well I gave netatalk (version from macbsd.com) a try.  First off, I have to

That file's a bit old.

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

Yep. :-)

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

Should be fine.

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

As mentioned below, that should be network interfaces. :-)

The printer is on LocalTalk bridged to Ethernet isn't it? We don't support
LocalTalk.

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

Have you tried again after setting the interfaces to the ethernet card
name?

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

If you're using the netatalk filters, there is NO physical connection.

In that case, the only thing which the lp device is used for is to control
access to the queues. 

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

I'm not sure. But you're mixing two different ways of communicating with
the printer. I'd sugest use only one for now. Either use Netatalk & a
LocalTalk bridge, or use a serial connection.

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

Your postscript isn't getting through right.

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

Shouldn't be a problem here.

Take care,

Bill