This is Qs-and-As in view mode; [Up]
Date: Sun 15-May-1989 15:03:52 From: Unknown Subject: Q's and A's 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 (617) 276-7757 >From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.