[comp.sys.next] Q's and A's

rose@atexnet.UUCP (Robert Rose) (05/15/89)

Here's some bits from my original posting, with J Greely's
comments, plus some extras at the end.  BTW, I'm not sure mail
can get though to me with the information here.  If you
want to send directly, do this:
...ll-xn!atexnet!rose
that usually works!

Bob Rose

================================
>FONTS:
>Any word yet on getting some more fonts?  I assume Adobe is working
>on it  (we use Optima a lot here in Kodak!)

>Adobe did announce that they were working on getting their entire font
>library ready for use on NeXT machines, presumably in the same price
>range they use for the PC and Mac worlds.

We just got a package from Adobe for some preliminary fonts.  We'll get
them and I'll let you know what I think.  If any Adobe'ers are
reading, when do we get Optima?  ;-)

>>LPR:
>>1) lpr <file> cuts off text on the right.  When you bring it into
>>Edit and Print it comes out OK.

>What happens if you use enscript?  And what do you mean by ok?  Is it
>that files too wide to be printed get chopped off from lpr, and
>wrapped from Edit and Print?  I consider this acceptable, since lpr is
>only doing what I told it to.  Of course, to conform in our
>environment, I'll be replacing /usr/lib/transcript/pstext with a
>wrapper for enscript (more reliable, and easier to reconfigure).  This
>will also make long lines wrap, but I can live with it :-).

We don't use enscript.  I guess you're right, if lpr is supposed to
just chop off stuff that's too far right.

>>PRINTING (from applications):
>>Many 'beta' applications fry PS when you try to print (FrameMake, sometimes
>>WriteNow).

>Well, FrameMaker doesn't appear to print through lpd, so it's *got* to
>be doing something wrong. (print from Frame with not enough paper;
>you'll never see an "out-of-paper" dialog box, and lpd will think all
>is well)

>  But I've never had a problem with the window system getting
>scrogged, just the printer.  What exactly happens to you?

I should have been more clear; the window server stays fine, it's just
that after it gets into some states I can't print ANYTHING anymore.
lpr an ascii file and the file sits in the queue (lpq will show it)
and it says printing, but it just stays there!!  The 'exit' hack
reset something and all is well.

>>If you're trying to use yellow pages logins (ie, the +:0::0.... stuff at
>>the end of /etc/passwd) and your home path is somewhere else (like on
>>a Sun) and there is no .NeXT directory in your home path, you can't log in.

>I can't duplicate that here.  Under 0.9, I haven't had anyone be
>unable to log in due to lack of a .NeXT directory.  Can you give me a
>precise repeat-by?  

Hmmmm, maybe if it could have found the home directory it would have
created the .NeXT directory, or at least known it was a real directory.
The problem could have been that my home dir is /homes/rose, and
/homes is an automount directory.  Before I set up /homes/rose on the
cube, I hoped it would go to my sun (but automount doesn't work
right --- at least I couldn't get it to).  Maybe it just has to find
some directory.

>>Also, the /etc/fstab file says it is not read if you're using netinfo.  
>>that's not true!!  I have some entries that mount my old sun's disks
>>in /etc/fstab, and whenever I reboot, it reads those and mounts my disks!

>Actually, it's not read unless you enable YP (see the manual for
>NetInfo).  I'm jealous, because I couldn't get it to do that, and
>ended up shoving my NFS mounts in NetInfo (which, with documentation,
>is pretty easy).  Part of my problem is that /etc/mount dumps core
>whenever I try to use it with the -a option.

Hmmm again!  Works for me;  "mount -a" works fine for me too!  Avadis??

>>MAIL:
>>1) No options for inserting file, and/or saving a letter as a file.
>>I do this a lot!

>I don't use Mail, but this would be a real problem if I did.  If the
>NeXT Mail program is less capable than standard Berkeley mail, I won't
>touch it.  Friendly user interfaces are one thing (and BSD mail needs
>one), but sacrificing features for tail-wagging is another.  All heat
>aside, it *is* a young program, and needs to be solid for the basics
>first, but I do hope someone is working on making it more capable.

It is a young program, so I'm forgiving, but I SURE HOPE it gets more
functional!

>>3)  The 'reply to' field isn't quite right.  The problem has to do with
>>domains, I believe.  When I send a message out, it looks like you can
>>reply to me with 'rose@onyx' (onyx is the CUBE) or 'rose@quartz'
>>(my Sun) depending on where I sent it from.

>How do you use the NeXT mailer from your Sun?  If both machines
>generate bogus reply-to's, the problem isn't in Mail.  I'm not sure
>what's wrong here.  This is one of those cases where the headers would
>be useful (so, if you sent me sample mail from both, I might be able
>to see what's going on.  Doesn't mean I can tell you how to fix it,
>but at least I should (he said, *should*) be able to tell you where to
>start looking).

I don't send NeXT mail from my sun (although I did say that, didn't I!).
I'll try sending you some mail, and if we figure out the problem
the net will know!

>>INTERFACE BUILDER:
....
>> a pointer to online docs in:
>>/NextLibrary/Documentation/NeXT/SysRefMan/07_IntfBuilder.wn

How did I miss that?  I've even been over there browsing.  I just printed
it, and I'll read em all!

>>2) When you bring up an application, sometimes it's menu in the upper left just
>>sits on top of the menu for the previous application!  It's hard to
>>reproduce, but it definetely happens sometimes!

>If the former active App is busy doing something (like Mathematica
>running a long calculation), this will happen.  I'd blame it on
>applications that aren't completely conformant with the interface
>guidelines yet.

Yep, I've been able to reporduce it; if an app is doing something.  This
isn't good, though.  The present app should have the ONLY menu up in the
upper left.

>>... Various stuff about c++, and why not have COBOL, etc.

I say c++/g++ only because it's EASY!! Getting COBOL on the NeXT
would be a BIG job with little gain.  I suggest this not only
for my gain, but also because I LIKE the CUBE and want to see it
succeed.  It would be a relatively small amount of time for NeXT
people to compile and possible include g++ with the box, or at least
confirm that cfront compiles and state "AT&T cfront Vx.xx compiles and
runs properly with these minor modifications" (hopefully a small
list of things!).  It's the 80/20 rule; a small amount of work for
a large relative gain.  


> lisp question...

Ahhh, I couldn't find it because I was looking in the NextApps, NextDevo, etc.
directories, and I was looking for 'lisp'.  It's called 'cl' and is
in the /usr/bin/ directory.   Seems to work.


One other thing, the printer dialog boxes should give an option for
printing back front (or vice versa)!  Everything comes out backwards, and 
I have to manually rearrage.

>-=-
>J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)

Thanks 'J', your replies are very useful!

Bob Rose
Eastman Kodak  Boston Technology Center
Bedford, MA

UUCP: ...ll-xn!atexnet!rose

(617) 276-7757