🚀 go-pugleaf

In article <18223@dcatla.UUCP> dudkl@dcatla.UUCP (Danny K. Llewallyn) writes:
>I have been playing around with invoking Diablo emulation mode
>via a PostScript program.  The way I wish to use it is to prepend
>it to an ASCII file for printing.  I have seen several other 
>methods for printing ASCII files most of them doing so by prepending
>an ASCII emulator to the file.  I do have a problem though with
>carriage return not working.  Line feeds work but carriage returns
>do not.  One question I have (for Glenn I guess) is "Do all
>PostScript printers support Diablo emulation?".  The program appears
>below.  Any help and comments are appreciated.

Well, first of all, no, not all printers support Diablo emulation.
Emulators are something that the OEM customer asks us to add to the
implementation.  It is obviously not a standard part of the PostScript
language.  I think that LaserJet emulators are more common than Diablo.

> [ code deleted ]
>
>But when I print on the next line, it only
>performs NL and not CR
>\004

The reason you are having trouble is that the printer thinks you are
executing a regular old PostScript program.  The CR NL pairs you send
it with the data are treated as a single EOL character by the
interpreter, which treats these as just white-space characters.  The
serial protocol filters them out before they even get to the
interpreter.  I'm not sure of the details of the Diablo protocol, but
if it needs ^D, ^S, ^Q, or ^T for anything, you are out of luck again,
because these are caught and interpreted by the protocol handler.
You really need the equivalent of "binary" mode for an emulator.

Normally (in more recent printers, at least) you invoke the Diablo
emulator with the "setsoftwareiomode" operator in statusdict (if it's
there; it's not a standard operator).  This turns off the serial line
protocol handler and treats the channel essentially as "binary" (modulo
parity settings and things like that).  This passes CR and LF through
transparently, and the emulator works as expected.

Since the channel is binary in emulator modes and won't recognize the
normal end-of-transmission signals on the serial line (good old
Control-D), it has no reasonable way of knowing when the job is done.
I believe that the special sequence ESC-DEL-0 (escape, delete, 0) will be
recognized by the emulator code and will return the inpterpreter to its
normal, PostScript-interpreting state.

I hope this helps somewhat.  Look through your documentation from the
manufacturer for anything about "setsoftwareiomode".  That will help
if your printer has it.

Glenn Reid
Adobe Systems