[fa.laser-lovers] More on printing Mac documents in the non-Mac environment on LaserWriters

laser-lovers@uw-beaver (07/07/85)

From: Alan Crosswell <US.ALAN@CU20B.arpa>

Here's a little more news on getting Mac documents to print when
the LaserWriter is not running on AppleTalk (i.e. is on RS232).

First,  a brief summary of what's been said about this stuff so far:

1) To get the PostScript source of a Mac document,  hit Command-F
   and hold it down for a while just after you select print from
   whatever Mac application you are in.  Instead of "Looking for
   LaserWriter" and printing the document,  the LaserWriter driver
   will create a file named "postscript" which contains the file
   that is normally sent over AppleTalk to the printer.  This is
   a valid PostScript file,  but it is missing something:  the
   definitions of the PostScript macros that it invokes (which are
   in the "md" dictionary).

2) The PostScript macros are defined in the "Laser Prep" file which
   is in the System folder of a "Laserized" disk.  They are stored
   as resources along with some other stuff (more on this later).
   Brian Reid posted these PostScript definitions recently along with
   a lot of very helpful comments.

Now,  what I can add to this:

1) Brian posted version 13 of Laser Prep,  but the version I got out of
   a LaserWriter box just last week is version 12.  I had trouble getting
   his version 13 to work.  The version number is in "av" in the md dictionary.
   Here's a program to print it:
	%!
	md begin
	/Times-Roman findfont 12 scalefont setfont
	100 720 moveto
	(md version is: ) show
	av (         ) cvs show
	showpage
	end

2) I have recently sent modified versions of rekamr, the resource
   decompiler, and rmaker, the resource compiler, to info-mac with
   support for decompiling and compiling the POST resource which is in
   the Laser Prep file. Using them you can get your own PostScript definitions
   out whenever you get a new Laser Prep (and you can modify them).
   Here's a summary of what (interesting) resources are in Laser Prep:
	LROM -  I dunno,  but sounds like something to do with the PostScript
		ROM version to me.
	POST -	There are several of these.  They contain the text of the
		PostScript commands.  Each POST resource has the following
		format:
			1st 2 bytes:	(binary) number of strings that follow
			followed by:	the above number of pascal strings
					(1st byte length and then data).
		Each string consists of one line of PostScript text.
	PSHX -	A bunch of binary data.  This may very well be 68K code or
		"compiled" PostScript.
   When you look at the decompiled POST resources,  you see that the last
   statement is "currentfile eexec".  Now,  there is no "eexec" command
   documented in Inside LaserWriter that I could find.  There is an "exec"
   command which executes commands from an input file whose handle is on
   the stack.  

   By spying on the AppleBus with Peek,  the sequence of data sent to the
   LaserWriter consists of all the POST's followed by the PSHX converted to
   hexadecimal.  This hex is immediately preceded by the "currentfile eexec".
   More on this later....

3) I popped into Emacs with the decompiled Laser Prep and did some minor
   editing to toss everything but the PostScript stuff and comment out the
   exitserver like Brian did.  I also commented out the currentfile eexec.
   I then cat'd this file with output from MacPaint (using the command-F)
   and shipped them all down to the printer with MacTerminal.  It worked!
   But ONLY when I set the smoothing argument of "dobits" false (see Brian's
   commented Laser Prep).

4) When smoothing was true (this is the difference between draft and final
   mode of the MacPaint print command by the way),  the printer complained
   that the "smooth" command was undefined.  Now,  Brian mentioned that the
   smooting function is proprietary,  and,  since it is not "built in",
   my guess is that the PSHX resource contains the code that implements it.
   So,  to get things to work completely,  you will probably have to dump
   the hex down also.  I haven't tried this yet but will report on my success
   or failure shortly.

5) The next step is to get this working with the Scribe picture command
   without trashing the environment.  This looks fairly straightforward,
   but you never know 'til you try it.  I think one thing that I will end
   up doing if I use this with RS232 and scribe is put it into the 
   permanent VM (i.e. exitserver) since it takes an awful long time to send
   the PostScript and hex down once for each job.  You can also run the
   machine under Appletalk and kermit your scribe output down to a Mac and
   use the Inside LaserWriter downloading program to print it (or get a
   SEAGATE!).

Alan Crosswell
Columbia University
User Services
-------