q4kx@vax5.cit.cornell.edu (Joel Sumner) (10/05/90)
On GEnie, there is a round table called DTP (Desk Top Publishing). They have many PostScript Fonts (PD? I guess so. They are free to download). They advertise them as 'Type 1' and 'Type 3'. I imagine they are used to download to LaswerWriter Printers. Can these fonts be used on a NeXT? Can they be 'downloaded' to NeXT Step DSP? Thanks... (BTW, what is Type 1 or Type 3? What is the difference?) -- Joel Sumner GENIE:JOEL.SUMNER These opinions are q4kx@cornella.ccs.cornell.edu q4kx@cornella warranted for 90 days or q4kx@vax5.cit.cornell.edu q4kx@crnlvax5 60,000 miles. Whichever .................................................... comes first. Never test for an error condition that you can't handle.
trevor@ficc.ferranti.com (trevor pugh) (10/13/90)
Does anybody know how much a NeXT cube n'all costs these days? I get conflicting answers to this question. Trevor
esht_cif@troi.cc.rochester.edu (Eran Shtiegman) (04/02/91)
When I save a postscript file to disk, upload it to a sun and try and print it using lpr it does not work. Does anyone know what I am doing wrong? Does the file have to be printed on a next printer? I am trying to print to an Apple LaserWriter. Thanks, Eran -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Eran Shtiegman - - email: esht_cif@troi.cc.rochester.edu - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
eps@toaster.SFSU.EDU (Eric P. Scott) (04/03/91)
In article <13126@ur-cc.UUCP> esht_cif@troi.cc.rochester.edu (Eran Shtiegman) writes: >When I save a postscript file to disk, upload it to a sun and try and >print it using lpr it does not work. What EXACTLY does not work? Do you get error messages back? If so, what are they? > Does anyone know what I am doing >wrong? Not without more information. > Does the file have to be printed on a next printer? No. The NeXT printing package which is prepended to PostScript output takes care of simulating operators not available on "normal" PostScript printers. > I am >trying to print to an Apple LaserWriter. Is it a very old "original" LaserWriter (ROMs less than V47)? More information on this subject can be found in NextAnswers. -=EPS=-
pbiron@keynes.ucsd.edu (Paul Biron) (04/04/91)
In article <1461@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >In article <13126@ur-cc.UUCP> esht_cif@troi.cc.rochester.edu > (Eran Shtiegman) writes: >>When I save a postscript file to disk, upload it to a sun and try and >>print it using lpr it does not work. > >What EXACTLY does not work? Do you get error messages back? >If so, what are they? > >> Does anyone know what I am doing >>wrong? Yes, when there is a ps error in a print job, many times you get no feedback from the printer as to what the problem was (as you do in say, Yap, for example). Here's a little something that I picked up somewhere to help with debugging ps files. Just prepend this to the front of your ps file (e.g. cat errordict.ps yourfile.ps | lpr -Pprinter), and then any ps errors will be printed out so that you can see what they were (my guess in this case, the file uses a font such as Olhfs, which is on the NeXT but not on the Sun). --------------------------------Cut Here------------------------ %! % Error handler to be prepended to postscript files... % % HISTORY % 17-Feb-89 Dan Nydick (dan) at Carnegie-Mellon University % Created. % % define an error handler errordict begin /handleerror { systemdict begin $error begin userdict begin /str 40 string def initgraphics /Courier findfont 12 scalefont setfont 0 setgray /lmarg 72 def /hgt 720 def /nl {/hgt hgt 20 sub def lmarg hgt moveto} def lmarg hgt moveto (Postscript error detected) show nl (Error: ) show errorname str cvs show nl (Offending command: ) show /command load str cvs show nl (Stack:) show /lmarg lmarg 37 add def nl $error /ostack get aload length { str cvs show nl } repeat systemdict /showpage get exec end end end % userdict $error systemdict } def end %errordict --------------------------------Cut Here------------------------
jadeflcn@CSD4.CSD.UWM.EDU (Ivan Carl Roseland) (04/13/91)
Hello I am wondering if the PostScript display can be turned off on the NeXT. I am thinking (planning) to buy one relly soon. I am i right in thinking that postscript will take up extra time and memory ? If not then it won't matter if PostScript can be disabled or not. I am also wondering if there are any Modem cards out their I can use on the NeXT that have several incoming lines (MORE THAN 1). please email me the information or post it.... thank you.. Ivan Roseland, aka Jadefalcon jadeflcn@csd4.csd.uwm.edu \\\/ o0 __ !
izumi@mindseye.berkeley.edu (Izumi Ohzawa) (04/13/91)
In article <9104121915.AA04246@csd4.csd.uwm.edu> jadeflcn@CSD4.CSD.UWM.EDU (Ivan Carl Roseland) writes: >Hello I am wondering if the PostScript display can be turned off >on the NeXT. I am thinking (planning) to buy one relly soon. I am i right in thinking that postscript will take up extra time and memory ? If not then it Sure, you can type in "console" to the loginwindow. Then you will get a big dumb-terminal window without PostScript. You can run most Unix command line stuff from this. You won't have the NextStep environment, no windows etc, because the Windowserver is the PostScript interpreter for display and and printer. Izumi Ohzawa [ $@Bg_78^=;(J ] USMail: University of California, 360 Minor Hall, Berkeley, CA 94720 Telephone: (415) 642-6440 Fax: (415) 642-3323 Internet: izumi@violet.berkeley.edu NeXTmail: izumi@pinoko.berkeley.edu
waltrip@capd.jhuapl.edu (04/15/91)
In article <9104121915.AA04246@csd4.csd.uwm.edu>, jadeflcn@CSD4.CSD.UWM.EDU (Ivan Carl Roseland) writes: > Hello I am wondering if the PostScript display can be turned off > on the NeXT. I am thinking (planning) to buy one relly soon. I am i right > in thinking that postscript will take up extra time and memory ? If not then > it won't matter if PostScript can be disabled or not. > [...] Maybe you really don't WANT a NeXT. There are other nice boxes out there that don't use Display PostScript (e.g., Amiga) but do have UNIX available and do provide a GUI when you want it. The NeXT is all about NeXTstep and Display PostScript. It takes memory but it's fast and it's elegant (I think so, anyway). But it may not be just what you're looking for. Sure is nice, though, and I suspect that if you look into it, you'll find the speed is fine (on the 040's) and NeXTstep has a lot more to offer than any other GUI you've seen. Hope you'll agree and, if so, welcome to the world of NeXT enthusiasts. c.f.waltrip Internet: <waltrip@capsrv.jhuapl.edu> Opinions expressed are my own.
louie@sayshell.umd.edu (Louis A. Mamakos) (04/23/91)
In article <1991Apr22.212326.26982@csusac.csus.edu> severyn@athena.ecs.csus.edu (Niles Severyn) writes: > >I've been working with the file operator in postscript trying to open >files for writing (for debugging purposes). The interpreter is quite >happy to do it, however when I go out and try to find the file, it >doesn't exist. Sorry, you lose. I very much would like to be to use this facility as well to run the "distill" package, as I used to under Release 1.0. My understanding is that this capability was removed in the name of security. As a result my existing, working, application stopped working and I'm stuck without an alternative. I suppose that I could dig up an Apple LaserWrite and catch the stuff coming back down the serial port, but that seems such a shame given that I have a wonderful PostScript engine right on my desk at work and at home. Such a shame to cripple one of the best PostScript development platforms available without making some alternatives available (as at least one other vendor has) such as restricting the files created to being in certain directories. Call your NeXT salesperson and complain. I'm and disturbed that this capability was removed, and also that there was no notice of dropping support for that capability. I was hoping that it would reapper in some form in the 2.1 release, but this appears to not be the case. Please correct me if I'm wrong. louie
severyn@athena.ecs.csus.edu (Niles Severyn) (04/23/91)
I've been working with the file operator in postscript trying to open files for writing (for debugging purposes). The interpreter is quite happy to do it, however when I go out and try to find the file, it doesn't exist. I've even tried creating the file and letting write to that. No effect. I've been trying something like this: (/Users/staff/severyn/file) (w) file dup (Hello) writestring dup flushfile closefile I must be doing something wrong. Also, I tried opening (%stderr) for writing, it does it, but when it gets to the writestring, it returns an invalid access for that operator. Also, I was wondering (perhaps this question should go in comp.emacs), does anyone know of a mode for emacs for editing Postscript files?
mic@ut-emx.uucp (Mic Kaczmarczik) (04/24/91)
In article <1991Apr22.211904.8832@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >In article <1991Apr22.212326.26982@csusac.csus.edu> severyn@athena.ecs.csus.edu (Niles Severyn) writes: >> >>I've been working with the file operator in postscript trying to open >>files for writing (for debugging purposes). The interpreter is quite >>happy to do it, however when I go out and try to find the file, it >>doesn't exist. > >Sorry, you lose. > >I very much would like to be to use this facility as well to run the >"distill" package, as I used to under Release 1.0. My understanding >is that this capability was removed in the name of security. > >As a result my existing, working, application stopped working and I'm >stuck without an alternative. I suppose that I could dig up an Apple >LaserWrite and catch the stuff coming back down the serial port, but >that seems such a shame given that I have a wonderful PostScript >engine right on my desk at work and at home. I may be missing the point here, but for the Distillery, could you maybe use the pft program to communicate with your server, and have the distill program write the distilled code to the standard PostScript output? This should be pretty similar to talking to a LaserWriter over a serial line. I have not tried it, but something like cat still.ps myfile.ps | pft >myfile-distilled.ps might at least let you use the Distillery. The more general case is a pain, since there are some times you need to disable *all* write access to files (e.g. for print jobs submitted from systems you allow to print on your printer but nothing else). However, perhaps at least locally, Mach port-based authentication could be used to figure out the uid/gid to use for *some* class of file opens. That way, if you open an authenticated connection to the PostScript server, you can have the server open files with your access rights. I share your hope that this will be fixed in a later release (the sooner the better). --mic-- -- Mic Kaczmarczik | Unix/VMS Services | It's amazing how much ``mature wisdom'' UT Austin Computation Center | resembles being too tired. remark@{ccwf,emx,bongo} 1-0251 | The Notebooks of Lazarus Long
louie@sayshell.umd.edu (Louis A. Mamakos) (04/24/91)
In article <47755@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes: > I may be missing the point here, but for the Distillery, could you > maybe use the pft program to communicate with your server, and have > the distill program write the distilled code to the standard > PostScript output? This should be pretty similar to talking to a > LaserWriter over a serial line. I have not tried it, but something > like > cat still.ps myfile.ps | pft >myfile-distilled.ps > > might at least let you use the Distillery. I've actually tried to do this under Release 2.0, but there are some sort of buffering problems with pft such that the last bit of the output is truncated. I have not tried it again under Release 2.1 to see if that pft related problem is fixed or not. > However, perhaps at least locally, Mach port-based > authentication could be used to figure out the uid/gid to use for > *some* class of file opens. That way, if you open an authenticated > connection to the PostScript server, you can have the server open > files with your access rights. I share your hope that this will > be fixed in a later release (the sooner the better). An arrangment like this sounds like it might work just fine. So long as some *reasonable* solution is found to the problem, I'll be happy. But just disabling a working capability with no advance warning from a vendor is not a resonable solution. And that's the point I was trying to make. In the "old days", our mainframe vendors would give advance notice on the order of 6 months to a year of software and capabilities that they were intending to no longer support, as well as migration tools when appropriate. This gave customers with production applications time to transition their production applications before the operating system features that they depended upon disappeared. There was no pulling the rug out from under the customer. There was also continuing support of older versions of the system software for some period of time as well. If you didn't want to move to the latest and greatest, you could continue to use the "old" stuff. What do you think NeXT would do if you reported a bug in Release 1.0? They'd laugh at you and tell you to use 2.0 or 2.1 since that's the "supported" version of software. My point here is you can't have it both ways; either * you tell your customers ahead of time what to expect in future releases if you're only going to support the current release, or * you support multiple versions of software. How else can I build serious applications if I can't depend on capabilities and features? Is this a "real" computer or not? I got no response to the bug report that I submitted on this when Release 2.0 first came out either. In my case, I was depending upon this feature to take Adobe Illustrator files from a Macintosh which are replicas of the various forms that we use at the University (purchase orders, etc). We have a print queue in our network printing system that can merge the PostScript for the form with the ASCII text from our Large IBM system things on the TCP/IP campus network, and prints them on printers around campus. We can save pile 'o money by not needing pre-printed forms. We chose to use a NeXT platform because it is such a wonderful beast to do PostScript development on. Now I can't use it for that function as I was before. Thanks, guys. louie
new@ee.udel.edu (Darren New) (04/24/91)
In article <47755@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes: > The more general case is a pain, since there are some times you > need to disable *all* write access to files (e.g. for print jobs > submitted from systems you allow to print on your printer but > nothing else). No, no, no, no. All you have to do is disable writing to files you don't want the postscript code to write to. The root of the problem is that UNIX permission bits don't include a set for "network" or "not on this machine". Because of the fact that UNIX permissions have not kept up with the rest of the OS, I think anything based on user ID or other UNIX-style permissions are going to be "the Wrong Thing." (Of course, the "Right Thing" would be to add a forth rwx set for "not on this machine" and a fifth for "not on this autonomous network" which would both default to ---, which would also cure anon-FTP and UUCP problems. Yea, good luck.) The particular solution in the case of PostScript could be either 1) Allow writing to files only in certain directories, much like /uucppublic. In this way, you always know where to look for files and you can get them out of the way before running something else which might clobber these files. 2) Allow writing only to files which have been created within the current postscript context (or smaller). That is, do not allow *over*writing of files. I don't imagine it is especially common that applications want to append to files already existant, but I may be wrong. Since the postscript interpreter itself is presumedly protected, you could get as fancy as you wanted with proper changes, including using the sticky bit and stuff like that. The most fancy solution might be this: Have a subdirectory for each UID, say /usr/spool/postscriptout/me and so on. All output to a particular PostScript device (like OUT:) goes there, and no other device is writable. If the sticky bit is set on the dir, then only creating new files is permitted, otherwise overwriting old files in this dir only is permitted. Doesn't seem too hard to implement. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+=+ My time is very valuable, but unfortunately only to me +=+=+ +=+ Nails work better than screws, when both are driven with screwdrivers +=+
mic@ut-emx.uucp (Mic Kaczmarczik) (04/26/91)
In article <51753@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >In article <47755@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes: >> The more general case is a pain, since there are some times you >> need to disable *all* write access to files (e.g. for print jobs >> submitted from systems you allow to print on your printer but >> nothing else). > >No, no, no, no. All you have to do is disable writing to files you don't >want the postscript code to write to. I was not advocating or approving the removal of all write access at all times; I was pointing out a common application where someone concerned about system security and reliability *would* wish to be able to disable it completely. I may not want random print jobs from other systems perusing world readable files or creating random files on my system, yet may still want to offer printing service. > The root of the problem is that UNIX >permission bits don't include a set for "network" or "not on this machine". Isn't the root of the problem that the Display PostScript server does not offer much in the way of authentication? One you connect to the window server, from wherever you are, you have as much (or as little) access as any other connection does. You can write to windows, delete windows, freeze the server, what have you, without ever dipping into the Unix file system. I think the DPS server needs to be more discriminating about who it accepts connections from. I don't want to arbitrarily let anybody else on the net poke at my server from another machine, but maybe I do want to run remote DPS applications. As far as I know, as things stand now I can't do both at the same time. >Because of the fact that UNIX permissions have not kept up with the rest of >the OS, I think anything based on user ID or other UNIX-style permissions >are going to be "the Wrong Thing." (Of course, the "Right Thing" would be >to add a forth rwx set for "not on this machine" and a fifth for "not on >this autonomous network" which would both default to ---, which would >also cure anon-FTP and UUCP problems. Yea, good luck.) I would certainly agree that the UNIX authentication scheme has problems in an open, networked environment. I'm glad to see that there are efforts like Kerberos that address the issue of network-based authentication and authorization. How about a DPS server that authenticates connections and file opens using Kerberos, and then uses your Kerberos credentials on your behalf to open files? >--- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- >----- Network Protocols, Graphics, Programming Languages, FDTs ----- > +=+=+ My time is very valuable, but unfortunately only to me +=+=+ >+=+ Nails work better than screws, when both are driven with screwdrivers +=+ -- Mic Kaczmarczik | Unix/VMS Services | It's amazing how much ``mature wisdom'' UT Austin Computation Center | resembles being too tired. remark@{ccwf,emx,bongo} 1-0251 | The Notebooks of Lazarus Long
louie@sayshell.umd.edu (Louis A. Mamakos) (04/26/91)
In article <47941@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes: > How about a DPS > server that authenticates connections and file opens using Kerberos, > and then uses your Kerberos credentials on your behalf to open files? Wow, funny you should mention this. We will most likely be using Kerberos authenticated AFS on our NeXTs anyway. There is a need for a real authentication mechanism to be in place to solve this and many other problems. And guess what, not all the machines that have to do this are NeXT platforms. All we need do now is to figure out how to shove enough of NetInfo out of the way to make this work. (How would you change your password on the Kerberos authentication server with Preferences? How about with `passwd'. Hmm.. And these are the obvious questions to ask.) I also agree that a public/non-public switch on the window server is not nearly fine-enough granularity. I hope the problem is solved by a real authentication mechanism (see above) where I can specify specific *users* and not just a list of IP addresses that I "trust." louie
waltrip@capd.jhuapl.edu (04/30/91)
In article <1991Apr26.044349.5265@ni.umd.edu>, louie@sayshell.umd.edu (Louis A. Mamakos) writes: > In article <47941@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes: >> How about a DPS >> server that authenticates connections and file opens using Kerberos, >> and then uses your Kerberos credentials on your behalf to open files? In the X world, I believe this is done by a session manager process which is separate from the X server (which is separate from the window manager). The session manager, of course, can rely on Kerberos authentication for identifying the node and user. The security (that is, the user and node combos which will be permitted to access my display) are specified to the session manager by the user. I wonder if a similar architecture could be adopted with the NeXT? > > Wow, funny you should mention this. We will most likely be using > Kerberos authenticated AFS on our NeXTs anyway. I, for one, will be very interested in how you accomplish this. I would be very interested in NeXT accomplishing it FOR us all (2.2?). > > There is a need for a real authentication mechanism to be in place to > solve this and many other problems. And guess what, not all the > machines that have to do this are NeXT platforms. > > All we need do now is to figure out how to shove enough of NetInfo out > of the way to make this work. (How would you change your password on > the Kerberos authentication server with Preferences? How about with > `passwd'. Hmm.. And these are the obvious questions to ask.) Again, would be nice for NeXT to supply all this. This is another area where NeXT could benefit by adopting a standard OSF/1 OS (or by joining the ACE consortium). Much of the stuff they are using their scarce resources on doing are being done by the OSF or ACE people. I'd like to see NeXT concentrate on NeXTstep and forget about operating system development that is already contained in the OSF or ACE world. > > I also agree that a public/non-public switch on the window server is > not nearly fine-enough granularity. I hope the problem is solved by a > real authentication mechanism (see above) where I can specify specific > *users* and not just a list of IP addresses that I "trust." > > louie c.f.waltrip Internet: <waltrip@capsrv.jhuapl.edu> Opinions expressed are my own.
louie@sayshell.umd.edu (Louis A. Mamakos) (04/30/91)
In article <1991Apr29.132216.1@capd.jhuapl.edu> waltrip@capd.jhuapl.edu writes: >> Wow, funny you should mention this. We will most likely be using >> Kerberos authenticated AFS on our NeXTs anyway. > I, for one, will be very interested in how you accomplish this. I > would be very interested in NeXT accomplishing it FOR us all (2.2?). The short answer is: we are going to license the NeXT sources and ruthlessly hack as much as we need to get the job done. Personally, I'm hoping that we can rebuild the shared C library to catch a good bit of this. As far as AFS is concerned, you can just buy it from Transarc. We have yet to work out who (Transarc or NeXT) is going to supply a modified loginwindow program which does the kerberos authentication necessary. Once again, we are licensing the AFS sources as well so that we won't be at the mercy of a vendor to get this stuff done for us. And some vendors wonder why we are so adament about being able to license source code for their products. Its to make their products usable in our environment, and not the one perceived by their marketeers. louie