tsai@iuvax.cs.indiana.edu (01/14/89)
In article from <abe@mace.cc.purdue.edu in iuvax:comp.sys.next> writes: > >There is source code for an application in Programming/Demos, called Yap, >that will display an arbitrary PostScript file. It opens en editor window >on the PostScript source, too, allowing you to change the source as you are >viewing its interpretation. ------------------------------------------------------------------------ Does anyone know how to print out the contents of a window generated from YAP? Here the printer isn't the NeXT's-- shared with other systems. And can we preview a PostScript file through NeXT's shell window? Thanks in advance.
ali@polya.Stanford.EDU (Ali T. Ozer) (01/15/89)
In article <1485@mace.cc.purdue.edu> abe@mace.cc.purdue.edu (Vic Abell) writes: >There is source code for an application in Programming/Demos, called Yap, >that will display an arbitrary PostScript file. It opens en editor window >on the PostScript source, too, allowing you to change the source as you are >viewing its interpretation. The source is in /MyDisk/Programming/Examples, and the executable is in /MyDisk/Programming/Demos. Unfortunately, Yap isn't suitable for previewing the output of programs such as TeX, word processors, CAD programs, etc. Yap doesn't know about bounding boxes, and nor does it know how to deal with multiple page documents. Yap, however, is good enough for previewing short Postscript code. Most people spend a few hours/days with the Adobe "Blue" book and Yap while learning Postscript; it's highly-interactive nature makes it suitable for such a purpose. Ali Ozer, NeXT Developer Support aozer@NeXT.com
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (01/15/89)
In article <6104@polya.Stanford.EDU> aozer@NeXT.com (Ali Ozer) writes: > >The source is in /MyDisk/Programming/Examples, and the executable is in >/MyDisk/Programming/Demos. Unfortunately, Yap isn't suitable for >previewing the output of programs such as TeX, word processors, CAD >programs, etc. Yap doesn't know about bounding boxes, and nor does it know >how to deal with multiple page documents. > Why should "Yap" have to know about bounding boxes & stuff like that; shouldn't the Postscript interpreter know how to deal with that stuff? Or is Postscript alone inadequate? >Ali Ozer, NeXT Developer Support >aozer@NeXT.com Matt Kennel, Princeton Physics Peon mbkennel@phoenix.princeton.edu
louie@trantor.umd.edu (Louis A. Mamakos) (01/16/89)
It is not too difficult to configure a PostScript printer in the spooling system which is either connected to another host, or is a real postscript printer (NEC LC890, LaserWriter, etc) on the serial port. The problem is that some of the PostScript code generated by the NeXT applications has non-standard postscript operator. These look like they are alpha-channel related. You can download a bunch of stub routines to the printer, and things seem to work after that. Note that just about all of the Adobe Transcript package is provided, including pscomm. But why no psgrind? Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
rfr@cs.cmu.edu (Rick Rashid) (02/08/89)
There is a very simple fix to Yap which, although it is not a perfect
solution, allows you to preview multipage documents.
In the sources to Yap (/bootdisk/Programming/Examples/yap/*)
you will find a file called 'controller.pswm'. In the method
'- executeRequest:(id)sender' there is a line which looks like this:
"/showpage {} def /yaptime usertime def \n",
You should change that line to be:
"/showpage {{buttondown {erasepage exit} if} loop} def /yaptime usertime
def\n",
This will cause the previewer to pause waiting for a mouse click each time
it finishes a page. Each time you click it will clear the window and
then process the postscript description of the next page. This hack has
the problem that it erases the entire window (including the border) but
I am very unfamiliar with postscript and this is the best I could do as a
quick hack. Perhaps someone with real postscript expertise could suggest
the correct thing to do rather than use erasepage.gore@eecs.nwu.edu (Jacob Gore) (02/10/89)
/ comp.sys.next / rfr@cs.cmu.edu (Rick Rashid) / Feb 7, 1989 / >...to preview multipage documents. >In the sources to Yap ... file called 'controller.pswm'. In the method >'- executeRequest:(id)sender' there is a line which looks like this: > > "/showpage {} def /yaptime usertime def \n", > >You should change that line to be: > > "/showpage {{buttondown {erasepage exit} if} loop} def /yaptime >usertime def\n", Nice. You probably want to define 'page' the same way. The problem is that everybody and their grandmother redefines 'page' and 'showpage'. If the document being previewed does that, this fix gets overruled. Any ideas? Maybe redefine 'def' so that it refuses to define 'page' or 'showpage'? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore
ali@polya.Stanford.EDU (Ali T. Ozer) (02/10/89)
In article <oXvpaAy00jdX0xKkUm@cs.cmu.edu> rfr@cs.cmu.edu (Rick Rashid) writes: >There is a very simple fix to Yap which, although it is not a perfect >solution, allows you to preview multipage documents. > ... fix: > "/showpage {{buttondown {erasepage exit} if} loop} def\n" > ... >This will cause the previewer to pause waiting for a mouse click each time >it finishes a page. Each time you click it will clear the window and >then process the postscript description of the next page. This hack has >the problem that it erases the entire window (including the border) ... Thanks for the code! Here's a version of the fix that will only erase the internal area of the window. Remember that Yap defines two variables, yapwidth & yapheight, that describe the size of the internal area of the output window. The following code waits for a mouse down on a "showpage" and simply erases that rectangle. We need to save the graphics state at the beginning of the program, however, to assure that any changes made by the user program to the gstate do not screw up are rectfill. We temporarily bring the saved graphics state (yapgstate) to focus everytime we want to do the erase. The following code, like Rick's, has the *massive* problem that it busy waits. The "while not buttondown" loop in the server really brings the postscript performance down. I'll post a better version of the following, without this problem, soon... Diffs to original controller.pswm: 65,68d64 < defineps CreateGState () < /yapgstate gstate def < endps < 144d139 < CreateGState (); 263,267c258,259 < fprintf (fp, "yapgstate currentgstate pop " < "/yapwidth %f def /yapheight %f def\n" < "/showpage {{buttondown {gsave yapgstate setgstate 1 setgray " < "0 0 yapwidth yapheight rectfill grestore exit} if} " < "loop} def /yaptime usertime def\n", --- > fprintf (fp, "/yapwidth %f def /yapheight %f def\n" > "/showpage {} def /yaptime usertime def\n", Ali Ozer, aozer@NeXT.com NeXT Developer Support