In <5B0D267B3C47D1119326080009DE9BA667A935@SEQUOYAH> [log in to unmask] writes:

> Chris Bartram wrote:
> > No fix; the workaround is to turn off PJL support on the
> > printer (in npconfig.pub.sys) and lose all ability to do
> > page-level-recovery.
>
> Chris,
>
> I've heard this a lot about printing to LaserJet printers but I still
> don't know what is meant by page-level-recovery. I've been using
> LaserJet's on our HP3000 for 10 years now. Even when we used serial
> connections and term type 18, if a page were to jam in the printer, the
> printer itself would reprint the incomplete page, or one page before the
> jammed page. So what is lost without PJL support?

That's page-level-recovery. With network-printing (as opposed to serial
printing) and a HP Laserjet 5si or newer, you have to disable the PJL
dialogue that would allow this same functionality. Older laserjets work
just fine, and serial printing (via DTCs) also works fine (as far as I know).

Apparently when they wrote the code for network printing, the PJL dialogue
(of the era) was (more or less) hardcoded in, making it difficult to extend,
and not forward-compatible with the new extensions that the new fancy lasers
use (i.e. multi-bin paper tray status reports, etc). In some tests I've done
with/for the HPRC, we found that sometimes we could get printing to work
fine with pjl enabled; in one case by emptying one of the optional feed trays
we then got the printer to loop printing one page of a printout repeatedly,
along with the associated console messages (unknown pjl sequence, or powerfail
message, depending on MPE & patch versions). My guess is that the printer was
adding status info warning that tray 2 was empty-  which is a warning since it
goes ahead and feeds from tray 3- but the spooler didn't know how to handle/
parse that additional "info" and "gagged" on it.

          -Chris