This is Gratuitous-incompatibility-with-NeXT-postscript-printer? in view mode; [Up]
Date: Sun 12-Feb-1989 23:34:44 From: Unknown Subject: Re: Gratuitous incompatibility with NeXT postscript printer? In article <1788@cps3xx.UUCP> riordan@frith.UUCP (Mark Riordan {of Systems}) writes: > [... ...] , what fonts are available for NeXT Postscript >support? I'm trying to figure out how likely it is that files >generated for a Laserwriter (perhaps by a PC wordprocessor) will >print on a NeXT. >Thanks. riordanmr@clvax1.cl.msu.edu As far as I can tell, only the Times, Helvetica, & Courier families and Symbol are available on 0.8. There is also a screen only font called Ohlfs that is sans serrif, & has larger x-height than Courier. (It is more legible on the screen than Courier is, but if you try to specify Ohlfs in ps code sent to the printer, it comes out in Courier. (Actually, anytime you ask for an unknown font when printing to the printer, you get Courier w/o any error messages that I can find.) Perhaps the LW+ fonts will be included in .9/1.0. -JimC >From: ali@polya.Stanford.EDU (Ali T. Ozer)
Date: Sun 13-Feb-1989 03:33:18 From: Unknown Subject: Re: Gratuitous incompatibility with NeXT postscript printer? In article <17945@vax5.CIT.CORNELL.EDU> James H. Cloos, Jr. writes: >As far as I can tell, only the Times, Helvetica, & Courier families and >Symbol are available on 0.8. There is also a screen only font called Ohlfs >... Perhaps the LW+ fonts will be included in .9/1.0. No; currently the plans are that the NeXT machine will be shipped with the above fonts and no others. Of course, other font families will probably be available from Adobe. Ali Ozer, aozer@NeXT.com NeXT Developer Support >From: zdenko@csd4.milw.wisc.edu (Zdenko Tomasic)
Date: Sun 15-Feb-1989 23:43:19 From: Unknown Subject: Re: Gratuitous incompatibility with NeXT postscript printer? In article <17633@iuvax.cs.indiana.edu> hess@iuvax.cs.indiana.edu (Caleb Hess) > > I recently began trying to use our NeXT printer. So far I have >found no problems with printing plain ASCII text files, but have been >unable to use some PostScript programs which work on other printers. For >example, Doctor Laser (published recently in comp.lang.postscript) does >not show any available fonts, although the rest of the page is printed (the >benchmark test result is quite good). > Also, Anders Ulfheden's showfont program (published recently in >comp.lang.postscript) simply vanishes. I have tried loading Adobe's error >handler, but it too apparently vanishes without effect, as no error pages >have ever been printed. > Are these programs doing things that aren't legitimate, or is >the NeXT PostScript interpreter a bit wimpy? The problem here is that Adobe changed where fonts are stored for Display PostScript. (The NeXT machine uses Display PostScript.) I believe if you change the string FontDirectory to SharedFontDirectory throughout those programs, and try it again, it will work better. For more information, get the documentation on Display PostScript from Adobe. - Terry Weissman weissman@wsl.dec.com ...!decwrl!weissman >From: hess@iuvax.cs.indiana.edu (Caleb Hess)
Date: Sun 15-Feb-1989 21:50:14 From: Unknown Subject: Re: Gratuitous incompatibility with NeXT postscript printer? I recently began trying to use our NeXT printer. So far I have found no problems with printing plain ASCII text files, but have been unable to use some PostScript programs which work on other printers. For example, Doctor Laser (published recently in comp.lang.postscript) does not show any available fonts, although the rest of the page is printed (the benchmark test result is quite good). Also, Anders Ulfheden's showfont program (published recently in comp.lang.postscript) simply vanishes. I have tried loading Adobe's error handler, but it too apparently vanishes without effect, as no error pages have ever been printed. Are these programs doing things that aren't legitimate, or is the NeXT PostScript interpreter a bit wimpy? >From: jec@iuvax.cs.indiana.edu (James E. Conley)
Date: Sun 17-Feb-1989 18:04:50 From: Unknown Subject: Re: Gratuitous incompatibility with NeXT postscript printer? [In my previous posting, I neglected to set the Followup-To field. I have corrected this oversight; further discussion of this topic is redirected to comp.lang.postscript only.] A Display PostScript expert has come up with the following better solution to the FontDirectory problem. Mine was a quick hack; his solution here is more elegant and will work on both printer PostScript and Display PostScript. 1. Just replace "FontDirectory" with [ FontDirectory {pop} forall /SharedFontDirectory where { /SharedFontDirectory get {pop} forall } if ] This simply builds an array of font names from both the private FontDirectory and the SharedFontDirectory, which is defined for Display PostScript systems. 2. Remove the leading "pop" from the "getfont" procedure because the array constructed in step one contains only font names. The program then works as advertised on both Printer and Display PostScript systems. Be default fonts that are loaded via findfont are put into SharedFontDirectory. If an application simply uses the "run" operator to load a font, it will be put into FontDirectory. This may lead to a font appearing more than once in the enumeration. The enumeration is the union of the fonts that are loaded in private and shared font directories. The VM statistics are less concrete in Display PostScript than they are in printers because the DPS system doesn't know in advance the maximum amount of storage the operating system will give to it. - Terry Weissman weissman@wsl.dec.com ...!decwrl!weissman >From: abe@mace.cc.purdue.edu (Vic Abell)
Date: Sun 01-Mar-1989 15:49:35 From: Unknown Subject: Re: Gratuitous incompatibility with NeXT postscript printer? In article <253@ccsrd14.UUCP> andrew@ccssrv.UUCP (Andrew Grant) writes: >I spent an evening 'playing' with a NeXT machine, a large chunk of which >was spent using Yap to examine the Display Postscript interpreter. In the >short time a had to look at it a noticed several incompatiblities between >the Display Postscript interpreter and the interpreter in Apple Laserwriter. >Yes the NeXT PostScript interpreter is a bit wimpy. The NeXT PostScript interpreter implements all of Display PostScript, which includes all of PostScript, described in the "Red Book," and the Display PostScript extensions, described in an document available from Adobe (and in the NeXT Tech Docs). There are also some NeXT extensions, such as compositing. Thus the problems you ran into probably aren't because the NeXT interpreter fails to implement all of PostScript. They could be because of --- - Yap problems; Yap doesn't deal with all errors as gracefully as it should. - Different limits; for instance there is a limit to the number of individual curves in a path. This limit might be different between different PS contexts in the server, it might change during runtime, and it will not be the same as the limit in some other PS interpreter. Another such limit is the default size of the user dictionary. (For instance, Brian Reid's Usenet maps do not run on the NeXT machine without creating a new dictionary first.) - Bugs in the 0.8 implementation. There are bugs, indeed. For instance, when a dictionary runs out of space, not always will you get an error back. Trying to run Brian Reid's maps through Yap or pft usually causes the interpreter to just sit there or return quickly without drawing anything. Only under certain circumstances you get a "dictfull" error back. Ali Ozer, aozer@NeXT.com NeXT Developer Support >From: feldman@umd5.umd.edu (Mark Feldman)
Date: Sun 06-Mar-1989 15:49:35 From: Unknown Subject: Re: Gratuitous incompatibility with NeXT postscript printer? In article <sY31Dcy00hl=40YdRP@andrew.cmu.edu> jhm+@andrew.cmu.edu (Jim Morris) writes: >It is possilbe to put a LaserPrep file in front of a Mac-generated PS file in >order to print it on a non-LaserWriter like a DEC LN03R or PagePrinter 40. Why >can't the same be done for the NeXT printer? If you are using the latest version of the Mac LW driver (the one that came with system 6.0.2), prepend LaserPrep (or use cmd-K), and then run this sed script on it: ---- cut here ---- 1i\ %!\ gsave 402,421d 82,83d 20,24c\ /ok true def\ /LW false def\ /waittimeout 300 def\ /fc {} def 8,18d $a\ grestore ---- cut here ---- The script strips out some LW-specific stuff (ok, LW, waittimeout, fc) and removes the 68000 object code that Apple downloads and executes in their printers. I've had good luck with it. Apple really does produce strange PostScript. Not surprising, as it's a call-for-call translation of Quickdraw.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.