Rereading my previous reply, I noticed that I really didn't answer Frank's
comments, thus please allow me to take up a little bandwidth and try again:
 
Frank Nagy wrote:
 
>Sorry to say but with my demo copy I had problems with the printing of the
>bar charts. I tried them on our HP 2562C, on an Epson FX1050, and on a
Laserjet
>II P printer. Some features seen on the screen were missing - either the
values
>of the X axis or the shadowing - if I could have combined the printouts of
the
>three printers then I would have got a perfect graph.
 
Although I am quite tickled that we've left PCL behind us, the PCL code that
QueryCalc generated should have worked perfectly. We were then and remain
very picky about quality and reliability, and all of the PCL graphics code
was extensively tested and used by a large number of users. I am sure the
problem was with the local hardware setup. Unfortunately, your problems were
not uncommon during the time that we supported PCL. The problem with PCL
printing is that are so many external processes are beyond the control that
we can exert while we're manipulating the graphic data on the HP3000.
 
The most likely cause of your problems was due to (i) printer
incompatibilities [including an incomplete implementation of even the
low-level version of PCL we used in one or more of those printers (I'm not
sure that an HP2562 supports much of PCL, and I'm even less sure about an
Epson)] or (ii) the fact that one or more these printers were connected to a
PC or a terminal rather than to the HP3000 directly.
 
Most HP terminals (and terminal emulators) strip out -- without warning --
certain control characters (NULL, ENQ, or DEL) and do not properly pass these
characters through the terminal to the slaved printer. While these characters
may mean something to the terminal, they can also be nothing more than
graphic bit patterns.
 
However, this deletion of characters is not universal in all HP terminals;
some don't do it (e.g., 2645) -- and some of the very old terminals (e.g.
2624) were configurable as to what characters would be stripped. Under any
circumstance, this sort of active remanipulation of the data stream  kills
PCL graphics [which ranges in decimal byte value from 000 (white) to 255
(black)], but does not severely affect text pass-throughs. Seven bit ASCII
re-transmitters clearly also do just as much harm, but in different ways, as
do active lans, repeaters, modems or any device that feels it must listen to
and modify the active data stream.
 
Over the years, we found that transmitting  PCL  graphics through anything
other than a wire that runs directly from the HP3000 to the printer is likely
to screw it up -- and with all data corruptions, the corruption is not likely
to be minor.
 
While I can guarantee that all of the PCL printing problems could have been
eventually worked out, it is difficult to express my relief at leaving all of
that behind. PCL was very slow to download, unreliable to retransmit, of
minimal graphics quality, exceedingly device-dependent, differently
implemented on virtually every printer it appeared on, and very resource
consumptive to the host. But other than for those few faults, it's not bad
language.
 
Wirt Atmar