Richard Gambrell writes:
 
>Wirt,
>This is really off the list topic, but it might clarify
>for some of us. I have often heard good things about
>Postscipt, but it is not my experience from using it with
>PCs and MS Windows. If you know, why do MS Windows
>printer drivers take so long to produce postscript and so
>little time to produce PCL?
>Also, postscript seems to require mega-memory on
>printers compared to PCL.
 
Actually, I would argue that the subject of graphics on the HP3000 is
absolutely core to the subject of this list.
 
On the day that HP decreed that all graphics should be removed from the
HP3000, the nature of the HP3000 fundamentally changed. Client/server was no
longer simply an option. Rather, from that point on, if you agreed with HP's
recommendation, you were condemned to downloading information into a PC if
your were to analyze and and graphically display data the data contained in
your databases.
 
HP began the campaign to remove all graphics from the HP3000 in 1985-6 when a
great many of its larger HP3000 Series 70 customers were complaining bitterly
about being "maxed out" and the RISC machines were obviously going to be much
later than they had promised. Removing all ancillary programs, such as
spreadsheets, word processing, and graphics was nothing more than a way to
buy a bit of time. By returning the HP3000 to its primary core function,
database manipulation, the HP3000 could be seen as remaining a viable machine
and HP could forestall many of its customers from moving to other platforms.
 
At the heart of this decision lay the extreme inefficiencies associated with
the implementation of HP's VisiCalc (it was a resource hog of the first
order; it is difficult to imagine how it was written so badly) and the
similar inefficiencies of the several graphics packages that were then common
on the HP3000. The graphics packages were  exceedingly resource consumptive,
but no amount of efficient coding could have overcome the basic handicap
associated with the general design path chosen.
 
All graphic images are composed of pixels (bit maps). You only have two
places where you can build the bit map, either in the host computer or in the
printer. If you choose the first option, you can build cheap, inexpensive,
simple printers that need only have enough memory to store one or two raster
lines of data. The image is simply printed as it is received from the host.
But this design choice places an enormous burden on the host computer,
whether it is a PC or an HP3000 -- especially when it must support any number
of different types of printers with varying resolutions.
 
Consider the following numbers: a 300dpi, 8.5 x 11 inch image requires 1.05MB
of memory (300 x 300 x 8.5 x 11 / 8) [the division by 8 is there because
there are 8 bits/byte]. Similarly, a 600 dpi, 8.5 x 11 inch image requires
4.2MB, and a 1200dpi image will require 16.8MB. And a four-color (cyan,
yellow, magenta, black), 1200dpi image will require 67.2MB.
 
There's no way to get around these memory requirements; the image must be
created in either the host or the printer. Wherever it is created, the
necessary memory must be allocated so that each bit (or group of bits forming
a pixel) can be turned on or off as the image is built. And in a Series 70,
the largest HP3000 available at the time, 8MB was the machine's limit.
 
If you choose the design path that builds the image in the host, you are
faced with a number of significant problems, the most troublesome being that
you must support a great many different printer types, both now in existence
and ones yet to be  built. The easiest way to do that is build some sort of
semi-device-independent file (bit-map) structure by adopting, say, a 1200 dpi
fixed definition standard and writing drivers (which are now often called
"filters") to translate your programmatically-manufactured 1200 dpi image to
whatever resolution is necessary, as is done in MS Windows when its native
GDI (graphic design interface) files are translated into
PostScript-compatible bit maps.
 
A simple way to do this is simply skip three bits out of every four in the
first line to be transmitted if you want to print to a 300dpi printer, and
then skip the next three lines before resuming. A more elaborate method would
weight each 4 x 4 square and then transmit a one or zero based on the result.
In either case, this simple filtering, retranslation, and data packaging
imposes no small burden on the host.
 
But this filtering/data re-packaging cost is insignificant compared to burden
imposed by the original generation of the graphic image. A surprising amount
of computational burden is imposed if you want to fill just one wedge of a
pie chart with a 50% gray fill and then draw a moderately thick black line
around the outside edge of the wedge. The problem is magnified exponentially
if you wish to fill the wedge with a gradient pattern, varying in color
across the wedge from light peach to dark salmon.
 
On a slow processor like the Series 70, with limited memory, even the simpler
task becomes a killer process -- and it's very reasonable to want to get it
off of the HP3000. Indeed, the only reason to continue with this design path
is if cost is an overarching concern. By putting all of the graphics load on
the host, you can keep the printers very simple and very cheap. Indeed,
there's no requirement to make the printer much more than a paper delivery
device that moves the paper underneath some sort of print head. With a PC,
taking this design path may initially seem reasonable.
 
Virtually all printers below $700 are designed in this fashion; the image is
created in the host and downloaded, raster line-by-raster line. But cost
containment is absolutely the only reason you would ever want to this design
approach.
 
Removing all graphics from the HP3000 was a draconian approach to the
problem. Rather than kill the goose, it would have been far better to simply
have redesigned the goose and change the algorithm.
 
Consider the alternative. PostScript is not the only possible graphic
description language, but it is certainly the most well done and by far and
away the most common. It has been implemented with a great deal of care,
pride, and integrity by Adobe Systems, and I am truly impressed with the
quality of the product. Almost all magazines (if not truly all) are created
in PostScript; that includes TIME, Newsweek, USA Today, Scientific American,
etc. And PostScript printers have dropped in price dramatically. Lexmark has
a 1200dpi, 12ppm PS printer now available for $1300.
 
The first implementation of PostScript was in the first Apple LaserWriter in
1984; in fact, PostScript is what made the Macintosh successful. The
shockingly good quality that came out of the first Macintoshes revolutionized
the way professional typographers and graphics artists now conduct their
business -- and is the reason why the people at TIME Magazine feel compelled
every so often to pay special homage to their Macintoshes.
 
And yet PostScript is surprisingly simple to implement in any host.
 PostScript is no more than FORTH in new clothes: a calculator-imitative,
stack-based RPN language, where the operands preceed the operators. To
command a printer to draw a 1 x 2 inch, 50% gray rectangle, with a dark,
black line around the box, all the code that needs to be emitted by the host
is:
 
   100 200 moveto 144 0 rlineto 0 72 rlineto -144 0 rlineto
   closepath gsave 0.5 setgray fill grestore 0 setgray stroke
 
(There are 72 points to the inch, thus the 72's and 144's)
(moveto = establishes a "current point")
(rlineto = draws a line to a point relative to your current point)
(gsave/grestore = saves and restores the current graphics "path")
 
This code can be made even more general by substituting user-chosen variable
names (xstart, ystart, height, etc. )for the fixed values, and rewritten:
 
   xstart ystart width 0 rlineto 0 height rlineto -width 0 rlineto
   closepath gsave fillcolor fill grestore linecolor stroke
 
Moreover, this fragment of code can be entered into the user's dictionary
(made basically into an "intrinsic" or subroutine) by defining it as a
PostScript procedure by enclosing it in braces and giving it a name:
 
   /box {xstart ystart width 0 rlineto 0 height rlineto -width 0 rlineto
   closepath gsave fillcolor fill grestore linecolor stroke} def
 
Now, the "box" procedure can be called at will to draw a rectangular box of
any height/width aspect, located anywhere on the page, and filled with any
color, as in this example:
 
   /xstart 100 def
   /ystart 200 def
   /fillcolor {.5 setgray} def
   /height 72 def
   /width 144 def
    box
 
To get an HP3000 language, such as BASIC, to emit this code to a printer is
similarly exceedingly simple. The code might look like:
 
   1000 PRINT #1;"/xstart "+X$+" def"
   1010 PRINT #1;"/ystart "+Y$+" def"
   1020 PRINT #1;"/fillcolor {"+C$+" setgray} def"
      o
      o
   1080 PRINT #1;"box"
 
Such code places almost zero burden on the host. But more than thant, it not
only allows graphics to be put back on the HP3000, it allows HP3000 graphics
of exceedingly high quality. Look closely at a magazine like TIME or USA
Today. All of the graphics presented there are nothing more than simple
repetitions of the code above, but because PostScript is so information
dense, the most complicated, non-bit-mapped graphic in any of these magazines
takes only a few seconds to transmit across the country over a simple
9600baud modem.
 
Whether or not graphics exists on the HP3000 inherently completely changes
the nature of the way that the HP3000 will be used -- and perceived. If data
is to extracted out of a database and put into graphic format, doing it on
the HP3000 -- where only a few lines of code need exist between the IMAGE
intrinsic and the PostScript printing code -- the task is made enormously
(and the word "enormously" can't be exaggerated) simpler than downloading
that same information into a PC graphics program through multiple layers of
interacting programs.
 
But it's even more than that. If the graphic task remains on the HP3000, it
can be automated. That's simply not true in any feasible manner under the
client/server model. Downloading information into a PC will almost always
remain a manual task. And if it is automated using a variety of scripts,
macros, and "agents", it becomes an inherently and singularly fragile "house
of cards". If anything changes in the network (routers, lans, etc.) or in the
client or the server (software versions, hardware, etc), the sequence of
macros and agents fails catastrophically, with no clear idea of what, who, or
where the culprit was.
 
But even more damning to this design path is the fact that the client PC must
become the initiator/sequencer device. In a client/server universe, the
client requests and the server responds. Thus, if any attempt to automate the
process of data analysis is to be made, you must begin the process at the PC.
In doing this, you've moved your most critical processes to your most
unreliable platforms. Keeping a PC up and operating for months on end is
almost unimaginable, and yet that's precisely what being asked of you if you
attempt to automate client/server-based data analysis.
 
While it may initially seem a bit of an overstatement to say that the
presence or absence of graphics on the HP3000 fundamentally changes the
nature of the HP3000, I don't believe that it is an overstatement. Simple
decisions often have far reaching and extraordinary consequences.
 
Downloading information into a PC is no less resource consumptive than
extracting the data on the HP3000 alone, but it is significantly more
complex, complicated and unreliable. The far better design path would be to
make the HP3000 into a Macintosh-like device: extremely simple to operate,
self-contained, hard-as-nails robust, and exceptionally reliable. These
"Macintosh-like" qualities are precisely the qualities that have come to be
so much admired in the HP3000; I am concerned that they are slowly being
whittled away by the complexities inherent in the client/server approach. The
far better option would seem to be to work hard to make the HP3000 as simple,
efficient, and easy to use as a Macintosh.
 
Wirt Atmar
 
 
Finally, as a postscript on PostScript: to specifically answer Richard's
question about PostScript under Windows and why it is taking so long, I am
reasonably sure that Windows must be translating its "native"graphical bit
map into a PostScript image format, which is simply another bit map format.
I'm sure that you're seeing the computation cost of this re-translation.
 
But if PostScript were being used properly -- using its command form as
explained above rather than as a bit map -- as a graphics description
language, a Windows screen composed of any number of boxes and lines, colors
and color gradients, should be capable of being formatted in less than 0.001
seconds of 486 CPU time and downloaded over a parallel port in less than a
second into a printer.