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 HetzelThe 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)