🚀 go-pugleaf

In article <21737@cup.portal.com> Murky@cup.portal.com (Gary A Murakami) writes:
> ... results are not the same as if I send the Diablo output to the
> LaserWriter when the mode switch is in the "Special" position.
> The printed output looks like linefeeds are done without carriage
> returns when the PostScript version is sent.  Example:

> This is line 1.
>               This is line 2.
>                              Each line should start at the beginning

Yes, this bit me when I was trying to do a PS loop to handle raw ASCII text.
The LW input routine maps CRLF pairs to a single LF, which handily explains
the behavior described above.  Quote from the FM, in this case the Red Book
Appendix D, Section "Serial IO", page 280, description of the LineFeed (10)
character:

"end-of-line: this is the PostScript newline character ... If a return and a
line feed are received in sequence, only one newline character is passed to
the POSTSCRIPT interpreter."

After reading Inside Postscript and dumping a few procedures I came upon a
flag in serverdict called "transparent" which is set in the Diablo and HP
emulation modes.  This appears to turn off the CRLF mapping stuff but it
also turns off the control-T status query and the control-D end of job stuff
which OUR SPOOLER DEPENDS ON.  We bit the bullet and moved the text to PS
translation back into the drive computer.

So, this is what is happening to you.  I don't have a good solution.

> The perplexing thing is that I can send it over AppleTalk to another
> LaserWriter and the output is just fine.

Right, Appletalk drive appears to bypass the CRLF mapping stuff, it must be
in a fairly low level of the SCC drive software.  Note that the Appletalk PAP
protocol provides an OUT-OF-BAND status query and job termination notification
indicator...
-- 
Sig     DS.L    ('ZBen')       ; Ben Cranston <zben@umd2.UMD.EDU>
* Computer Science Center Network Infrastructures Group
* University of Maryland at College Park