sandra@gonzo.UUCP (Sandra Burch) (02/11/89)
I tried sending a postscript file from a Sun to a NeXT machine on the network using the regular BSD lpr system. It queued just fine, but didn't print. There was an error message in a file on /tmp that said there was something wrong with the Postscript source. This is odd, because it prints just fine on a LaserWriter and on a DEC postscript printer. I'm not enought of a whiz to figure out just what is going wrong, but this is troubling. Are there different flavors of postscript? Does this mean programs that write LaserWriter standard postscript won't work on the NeXT without rework? Oooooooo, yuckers. Thanks! SKB -- "Babies are beautiful, by definition" -- Miss Manners sandra@gonzo.uucp
usenet@cps3xx.UUCP (Usenet file owner) (02/12/89)
In article <509@gonzo.UUCP> sandra@gonzo.UUCP (Sandra Burch) writes: >Are there different flavors of postscript? Does this mean programs that >write LaserWriter standard postscript won't work on the NeXT without >rework? Oooooooo, yuckers. Along the same lines, 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
jhc@vax5.CIT.CORNELL.EDU (02/13/89)
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 -- James H. Cloos, Jr. "Entropy isn't what it used to be." jhc@Crnlvax5.BITNET --c/o Fortune @ batcomputer.UUCP jhc@Vax5.CIT.Cornell.EDU #include <std_disclaimers.h> cornell!vax1!vax5.cit.cornell.edu!jhc@rochester.UUCP B-7 Upson Hall, Cornell Univ., Ithaca, NY 14853 +1 607 272 4519
ali@polya.Stanford.EDU (Ali T. Ozer) (02/13/89)
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
cplai@daisy.UUCP (Chung-Pang Lai) (02/14/89)
In article <509@gonzo.UUCP> sandra@gonzo.UUCP (Sandra Burch) writes:
]I tried sending a postscript file from a Sun to a NeXT machine on the
]network using the regular BSD lpr system. It queued just fine, but
]didn't print.
I thought the NeXT printer is just a dumb raster laser printer. The
PS intepretation is done by the Display PostScript on the host computer.
Will the problem caused by your lpr set up? If the printer is dumb,
something has to be done before the job is sent to the printer.
Just an uneducated guess :-)
--
.signature under construction ...
{pyramid, osu-cis, uunet, killer}!daisy!cplai C.P. Lai
cplai%daisy.UUCP@uunet.UU.NET cplai%daisy@killer.DALLAS.TX.USA
Daisy Systems Corp, 700B Middlefield Road, Mtn View CA 94039. (415)960-6961hess@iuvax.cs.indiana.edu (Caleb Hess) (02/16/89)
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?
weissman@decwrl.dec.com (02/16/89)
In article <17633@iuvax.cs.indiana.edu> hess@iuvax.cs.indiana.edu (Caleb Hess) writes: > > 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
weissman@decwrl.dec.com (02/18/89)
[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!weissmanandrew@ccsrd14.UUCP (Andrew Grant) (02/25/89)
In article <17633@iuvax.cs.indiana.edu> hess@iuvax.cs.indiana.edu (Caleb Hess) writes: > > 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? 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. Most applications generating Postscript assume they are talking to a Laserwriter, so they won't work with the NeXT printer. The need for Laserwriter compatiblity rather than Postscript compatiblity is the reason that so few Postscript 'clones' are currently available.
roy@phri.UUCP (Roy Smith) (02/27/89)
andrew@ccssrv.UUCP (Andrew Grant) writes: > The need for Laserwriter compatiblity rather than Postscript compatiblity > is the reason that so few Postscript 'clones' are currently available. Is this not a fault of the PS-generating applications, and not of the printers? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
ali@polya.Stanford.EDU (Ali T. Ozer) (03/01/89)
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
jhm+@andrew.cmu.edu (Jim Morris) (03/02/89)
> Most applications generating Postscript assume they are talking to a > Laserwriter, so they won't work with the NeXT printer. The need for > Laserwriter compatiblity rather than Postscript compatiblity is the reason > that so few Postscript 'clones' are currently available. 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?
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/06/89)
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. -- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765