Bruce writes:

> Wirt Atmar writes:

>  >In contrast, QueryCalc uses PostScript as its print language,
>  >thus the range of creatable forms is significantly greater (at
>  >significantly less computational expense).
>
>  This comparison is misleading. Any form that can be created on a
>  PostScript printer can also be created on a PCL printer.

Let me disagree reasonably vigorously with Bruce on this point. There are an
infinity of things that can be created on a PostScript printer that cannot be
created on a PCL printer.


>  The
>  computational expense for a PCL form is incurred once, when the form is
>  first created; thereafter, it's simply downloaded. Moreover, it's
>  downloaded only once per job -- unlike PostScript, where it's downloaded
>  with each page.

That's not quite true, either. PostScript Level 2 allows forms caching
(download once/reuse often -- although to be absolutely honest, we don't use
the feature in QueryCalc in order to be backwards compatible with Level 1
printers; however, Level 1 printers are rapidly disappearing from the scene
and we may change over to forms caching in another year or so, when the
probability level reaches near certainty that we'll never see a Level 1
printer. It is simply part and parcel of our business philosophy that a little
inefficiency is highly preferable when compared to the costs of having to
explain to an ordinary business user some arcane process that he or she will
have to invoke to make QC work with their equipment. The ultimate goal is to
have everything work the first time out of the box -- and every time
thereafter, with absolutely no excuses from us).


>  The computational expense for a PostScript form is moved from the host to
>  the printer, so the host won't see this computation. The operator most
>  certainly will, however.

Let me disagree one more time. QueryCalc, on a 917-sized box, will generate
600 pages of full color, high graphic level output per minute. The average
size of such a page (in bytes) tends to run only between 3K to 10K. Rendering
speeds in the printer tend to be at the page processing rate of the particular
printer involved.

For simple lines and boxes, you're not going to see any difference at all
between PCL and PostScript rendering speeds. PostScript only slows down when
the process becomes quite elaborate (or poorly written).

Indeed, when we first gave serious thought to adopting PostScript -- and later
again thought of completely abandoning PCL (for a whole raft of reasons, but
most especially the inability of HP to produce two printers that acted
precisely the same) -- five or six years ago I spent a great deal of time
intercepting downloaded PS code from our Macintoshes.

I relatively quickly discovered that almost all of the inefficiencies
associated with PS on a Mac are due to the manner by which Apple mediates
PostScript libraries on the Macintosh. An enormous amount of unused
information is downloaded with every print job on a Macintosh. Framemaker
files, for example, consume a megabyte on each download that would be only a
few K if generated in QueryCalc. Bad design is bad design -- and it's easy to
get rid of.


>  >But the
>  >quality of output is significantly (to greatly) better.
>
>  This is misleading in the extreme.

Again, I must disagree, but in Bruce's defense, Bruce may have misunderstood
what I was saying. Bruce went on to talk about printer resolution. I was
speaking about overall aesthetic image quality. There is a simple, objective
test to my statement. Count the number of books, magazines, newspapers,
advertisements, catalogs, etc. that are put together using PCL -- and compare
that number to PostScript-produced documents. I know of no professionally
produced output that is coded in PCL. It is all 100% PostScript (or one of its
phylogenetic cousins).


>  All of which may seem like I'm a PCL bigot. I'm not; I believe in using
>  the right tool for the job. All our desktop systems, even the PCs, drive
>  our printers using PostScript. Even our Unix system typically drives a
>  PostScript printer. They're much easier to set up; there's no big hassle
>  with downloading the right driver (and as several people have pointed
>  out, you can only expect good results from PCs if you constantly download
>  new drivers), and the results are highly predictable. PostScript printers
>  are trivial to support, even on a wildly heterogenous network.

On these points, I couldn't agree more with Bruce. In fact, Bruce's paragraph
above is worth rereading. These are exactly the points that I was trying to
make in the earlier posting.

If you're going to install an HP3000 into an office, these are exactly the
behaviors you want. Perhaps I shouldn't say it, but everything we're about in
QueryCalc's design is to essentially allow ordinary people to conduct their
business on an HP3000 and to be able to eliminate (or never have to hire) on-
site professional data processing managers to run the HP3000s. Over the last
15 years, I've grown to become extremely impressed with the talent and
intelligence that resides in office managers, bookkeepers, comptrollers, and
CEOs. The single great trick to letting these people do their work well is to
select extremely well designed, highly reliable technologies: the HP3000 and
PostScript are by far and away two of the best.

To reinforce Bruce's points, a few months ago, we purchased a Tektronix Phaser
560 color laser printer. All that was necessary to install it was to unpack
it, insert the color toner cartridges, and plug in the serial connection that
had just moments before been plugged into a LaserJet 4M Plus printer. No
reconfigurations of any kind were necessary on the HP3000. And it worked first
time, 30 minutes after arrival. Flawlessly. And every time since. I'm wildly
impressed with the quality of printer.

In that regard, I sent Bruce today, by FedEx, some samples of QueryCalc's
output. Everything in the packet I put together was produced on the HP3000, in
PostScript. And none of it is your father's electronic forms. Our letterheads,
our business cards, virtually everything we produce nowadays is created on the
HP3000, in QueryCalc, in PostScript.

If there is anything unfortunate about the material that I included in Bruce's
packet, it is that there is a repetitiveness to the material that I was able
to grab and get together on a busy day. More unfortunate yet, all of the
invoice-like forms that I have contain highly proprietary information on them,
thus I couldn't send them without taking the time to gen up similar results
with fake data, but he should be able to get a sense of what's possible from
the examples that I did send.

Does quality of output matter? If you're the electric company and need to
print 500,000 invoices -- and you don't give a hoot what the invoices look
like because you've got the customers over a barrel anyway -- then probably
not. But if you're printing only 1000 invoices, and you want to impress your
customers with the level of care and quality that you put into every aspect of
your business, then it most likely matters a great deal.

Wirt Atmar