Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site uw-beaver
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!laser-lovers
From: laser-lovers@uw-beaver
Newsgroups: fa.laser-lovers
Subject: Re: Apple Laserwriter XON/XOFF problem
Message-ID: <1688@uw-beaver>
Date: Thu, 31-Oct-85 23:57:40 EST
Article-I.D.: uw-beave.1688
Posted: Thu Oct 31 23:57:40 1985
Date-Received: Sat, 2-Nov-85 06:23:33 EST
Sender: daemon@uw-beaver
Organization: U of Washington Computer Science
Lines: 29

From: Allan Hetzel  

The note posted to Laser-Lovers on Oct 28 by Joseph Goldstone of Symbolics
Cambridge Research Center was helpful but I didn't try his suggested fix
correctly and so I called Adobe.  They were very helpful (much more so than
Apple) and explained the problem and how to bypass it.

My apologies to Adobe if this not an accurate description of the problem.
The problem apparently is due to the PostScript interpreter getting confused
by what it thinks is an excess of white space characters.

The bypass is to place a special character (parenthesis, bracket, brace,
slash, etc.) to the right of some token, but without an intervening white
space character. As the PostScript scanner reads the token it also reads the
special character which acts as a delimiter. The scanner then has to back up
one character so that it can reprocess the special character after it has
processed the preceding token.  During this backing up process a number of
internal values are recalculated, including some pointer into the input buffer.
This causes the XON/XOFF protocol to work properly.  Doing this once per page
seems to keep everybody happy.

Each page in the PostScript file built by our word processing program is
surrounded by a "save restore" sequence. We changed the beginning save
sequence "/saveobj save def" to read "/saveobj save def() pop".
The "() pop" is effectively a no-op and we are assured that the necessary
recalculations are done on each page.  This seems to have corrected the problem
completely.

Allan Hetzel (sysal@ukcc.bitnet)