Laser-Lovers-Request@WASHINGTON.ARPA (Moderator) (01/12/86)
Info-Postscript for Laser Lovers Digest Saturday, January 11, 1986 10:26PM
Volume 1, Issue 4
Today's Topics:
Printing LaserWriter Files
Path values
Postscript Misc.
Re: Postscript Misc.
Error handling, etc.
Re: Error handling, etc.
HP 7475 emulator??
----------------------------------------------------------------------
Date: Mon, 2 Dec 85 17:26:02 cst
From: oakhill!eifert@sally.LOCAL (Jim Eifert)
Subject: Printing LaserWriter Files
We have just obtained a laserprinter (postscript) from Apollo
which claims to print 26 pages per minute. We are a Beta
test site. Right now, the printer is connected to an Apollo
using a 19200 baud serial line.
We would like to be able print files that have
been generated on the Macintosh for the LaserWriter.
We can get the Mac to generate a postscript file,
but the Apple laserwriter is initialized so that it
retains some basic graphics routines internally.
Can someone send me or tell me how to obtain the Mac
postscript file which defines some of the graphics
routines so that we can use it to print on our Apollo
laserprinter?
Thanks,
Jim Eifert
oakhill!eifert@ut-sally.arpa
------------------------------
Date: Tue, 3 Dec 85 11:58:35 est
From: ned%UPenn-Grasp%upenn.csnet@CSNET-RELAY.ARPA
Subject: Path values
Is there some good reason that PostScript doesn't allow a path as an object
type? Obviously there are provisions for the maintenance of more than one path
at a time (the current path and the clipping boundary), so why not allow a lot
more, and pass them around as values? A lot more interesting operators on them
could be defined, and the current ones generalized to take a path on the stack.
As a workaround, has anyone done anything with converting the path to another
representation and back so that they can be stored some other way? (Another
case where the pathforall & charpath restriction is a real pain! :-( )
--Ned
ned@UPenn.CSnet
------------------------------
Date: Tue 17 Dec 1985 14:02:30 EST
From: Bob Pellegrino <primerd!bobsun!bob@mit-eddie.MIT.EDU>
Subject: Postscript Misc.
We at Prime have had experience with preliminary versions of
several PostScript printers, communicating over the serial interface.
We have posted notices previously giving speed comparisons. It
should be noted that nobody other than Apple or Allied has brought a
product to market, so comparisons with the LaserWriter and Linotronic
machines should not be thought indicative of the manufacturers'
relative merits.
The fact remains that the LaserWriter is approaching its first
birthday, and I (DWB) for one remain astounded at the resilience and
bugfree-ness of the first reasonably-priced PostScript printer.
Experience and common-sense teach that the first implementation of
anything should be the one with the most problems. The LaserWriter is,
simply, magic. Thank goodness -- I'd hate to be the Apple manager who
orders the first ROM replacement.
It even prints, beautifully, a 5-megabyte grayscale image -- portions
of the Mandelbrot Set (See Scientific American, November, p31). It
takes 90 minutes to produce one page, which is the time taken to ship
the data at 9600 baud. No overhead for actually forming the image.
Of course, there are bugs in addition to those reported in "Apple
LaserWriter Supplement" and the PostScript Reference Manual. After a
lot of printing of multifont documents, it can get suddenly confused
and pick the right characters out of entirely the wrong font. The only
cure is to reboot (write your printer management software to stand for
unsolicited reboots!). And an attempt to shear a large grayscale
picture breaks it.
One unpleasant feature concerns software selection of onboard Diablo
emulation. We would like to run our printer in a standard spooling
environment, where each job is independent and the printer runs
unattended. If one job wants to use the Diablo emulation, it has a
problem. Either (a) you can get the printer into Diablo mode, but you
can't get it out again or (b) you can call on the emulation in such a
way that the server still notices and interprets control-C, control-D
and control-T. Since these are valid arguments to Diablo commands, the
job pretty soon aborts. Anybody found a way round this?
One other complaint. Some of you folks are writing Mac-LaserWriter
software to use the full 8-bit bandwidth capability of AppleTalk. We
like to capture your PostScript file, forward it (via our EXCELLENT
link software) to a host, and then print from the host either as is, or
pasted into another document. This works with most MacDraw/Paint
files. But if you use the 8-bit bandwidth, the serial input protocol
strips the top bit and makes a mess -- that's if our own host software
hasn't done so for itself by then.
Happy PostScript hacking!
Bob Pellegrino
David W. Brooks
Prime Computer, Inc.
UUCP: decvax!genrad!mit-eddie!primerd!bobsun!bob
ARPA: Pellegrino@bbna
------------------------------
Date: 18 Dec 85 14:39:57 MST (Wed)
Subject: Re: Postscript Misc.
From: =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) <thomas%utah-gr@utah-cs.arpa>
You write:
>But if you use the 8-bit bandwidth, the serial input protocol
>strips the top bit and makes a mess -- that's if our own host software
>hasn't done so for itself by then.
I have two comments:
1. It's very hard to avoid generating 8-bit characters, without
rewriting the laserwriter printer driver on the Mac. If you use any
'option' characters, these will come out with all 8 bits significant.
2. It's trivial to write a program that translates 8-bit characters into
the appropriate \nnn notation. I enclose one below.
=Spencer
/*
* xlw.c - Fix up Mac PostScript files to send to LaserWriter.
*
* Author: Spencer W. Thomas
* Computer Science Dept.
* University of Utah
* Date: Wed Jun 5 1985
*/
#include "stdio.h"
main( argc, argv )
char **argv;
{
FILE * f;
int i;
printf( "%%!\n" );
if ( argc == 1 )
{
f = stdin;
goto once;
}
for ( --argc, ++argv; argc > 0; argc--, argv++ )
{
if ( (f = fopen( *argv, "r" ) ) == NULL )
{
perror( *argv );
continue;
}
once:
while ( (i = getc(f)) != EOF )
if ( i & 0200 ) /* meta char? */
printf( "\\%03o", i );
else
putchar(i);
}
}
------------------------------
From: decwrl!allegra!utzoo!aesat!jalsop@glacier
Date: Fri, 20 Dec 85 02:36:50 pst
Subject: Error handling, etc.
Would anyone care to share their thoughts on the best ways to deal with
Postscipt printer error conditions?
For example, in designing a spooler for a Laserwriter, what is the best way
to recognize and deal with Postscript programming errors in individual
print jobs? How can power failure, paper jam, and other physical printer
problems be recognized and recovered from?
John Alsop @ AES Data Inc.
{allegra,ihnp4,linus,decvax}!utzoo!aesat!jalsop
------------------------------
From: adobe!shore@glacier (Andrew Shore)
Date: 20 Dec 1985 1316-PST (Friday)
Subject: Re: Error handling, etc.
I'm going to attempt a fairly general answer since I'm not
exactly sure what John wanted to know.
The execution of a PostScript print job may result in arbitrary
output over the communications stream back to the host that is
sending the job. In serial communications with a LaserWriter,
there is only one output stream which may contain:
user output (arbitrary "print" or "write*" output)
printer error messages (see below)
PostScript execution error messages (see below)
"out of band" status messages (response to ^T requests)
job control/synchronization messages (^S/^Q flow control and ^D end of job)
Within a single print job, printer stream output may be (WILL be)
unsynchronized with stream input (i.e., the sending of that job).
The TranScript spooler interfaces use two processes -- one for
sending the PostScript job (followed by a ^D) to the printer, and
one for listening to the printer for any stream output (it
terminates when it hears the printer's ^D in response). Flow
control is handled by the UNIX tty device driver.
Under serial (RS232) communication, when the LaserWriter power fails or
some disastrous situation causes a hard PostScript reboot. The
Data Terminal Ready (DTR) signal goes away. On UNIX systems, this
can be detected by noticing a hard end-of-file on the tty device
(getc returns -1).
Note that other communications protocols may have different
properties. AppleTalk, for example, allows full 8-bit data to be
passed, as flow control, job status, and job start and end are not
embedded in the data stream. Other network protocols may have
several output streams. One for user output, and one for errors,
etc.
Printer Errors
--------------
Printer error conditions are fairly machine-specific. Some printer
interfaces can return detailed status information about how and
where a printer has failed, other can simply note that a generic
failure occurred.
The representation and handling of printer error and printer status
conditions is not strictly part of the PostScript Language
definition. Rather, these are relegated to the area we call
"statusdict", of product-specific operators and extensions to the
PostScript base language.
Physical printer problems are detected by the PostScript
interpreter. On failure of the Canon engine during execution of a
showpage or copypage operator, the PostScript interpreter calls a
procedure named "printererror" in statusdict. The default
operation of printererror is to send a message over the output
communications stream. These messages are of the form:
%%[ PrinterError: <reason> ]%%
Where <reason> is usually (but not always) some reasonable string
representation of the error condition. Unfortunately, the Canon
interface sometimes reports bogus status information when the
printer state is in transition. For example, when the paper tray is
removed and reinserted, some untrue or undecipherable <reason>s may
appear in new messages. Untrue being things like "service call"
and undecipherable being short strings of hex digits. This is a
not-too-terrible problem with the LaserWriter.
Execution of the job in progress (and the showpage in progress) is
suspended until the error condition is cleared, and then the
showpage is "resumed" (and repeated until it succeeds).
TranScript parses PrinterError messages and (on 4.2 systems)
posts a notice in the spooler "status" file (so that it can be
seen in lpq and lpc status requests).
PostScript Execution Errors
---------------------------
PostScript job execution errors are handled as described in the
PostScript Language Reference Manual. On the LaserWriter, these
save some state information about the error and execute a "stop"
which, if uncaught, sends an error message over the output stream
and aborts the current job. Adobe has distributed a downloadable
"error handler" package which also prints some information about
the error on the current page.
TranScript records the error message output in the printer log file,
but performs no special functions on a PostScript error.
I can say more about all of these things if there is interest,
but I've gone on long enough.
Happy Holidays,
--Andy Shore
Adobe Systems Incorporated
------------------------------
Date: Thu, 2 Jan 86 11:01:55 pst
From: Neal Holtz <holtz%cascade.carleton.cdn%ubc.csnet@CSNET-RELAY.ARPA>
Subject: HP 7475 emulator??
Does anyone have postscript code to emulate any of the small HP
plotters, that they would be willing to give out?
Preferably HP 7475, though I don't know what difference there
might be from other HP's.
We have some masochists here that use PC clones, and Autocad,
and I suppose that is one way of getting output on our LaserWriter.
Or does anyone know if Autocad will soon support PostScript?
------------------------------
End of Info-Postscript for Laser Lovers Digest
**********************************************