Mark Bixby wrote:
> Jeff Kell writes:
> > Is anyone successfully using LPQ-1200 printers with Net Printing?
>
> Sort of. :-(
> > At first glance, it looked like everything was working. The printer
> > runs in PCL-II emulation mode and seems to get along with network
> > printing with pjl_supported = TRUE. Then things went terribly
> > wrong.
> PJL/PLR does initially seem to work, but eventually becomes terribly
> brain damaged. I've tested this on the latest firmware.
Thanks for the warning.
> The official word from the printer division is that PJL/PLR is not
> supported yet on the LPQ printers. *Maybe* by the end of the year.
> Aside from PJL/PLR, we have a *MULTI-YEAR* software call open
> regarding the network spooler's improper (IMHO) handling of %102/%103
> perf-skip CCTLs.
We've had a few of these, but worked around them with raw PCL coded into
the applications. However, I discovered a new one today...
Using Steve Davidek's suggestion of making a "null" setup file for the
printer, it now prints with the correct horizontal spacing and our forms
work again. However, our applications are largely COBOL and use the
LINEAGE feature on print files. For the COBOL-challenged, this means
that programs generate no true form feeds, but rather uses pre-spacing
and the %2nn series carriage controls to "skip nn lines" to go to the
top of the next page. This enabled us to abandon VFC's for nonstandard
form lengths (invoices, bills, mailers, etc) but it is coming back to
haunt us. The original default setup for network printing when no ENV=
or setup_file was specified uses some detailed vertical spacing that
gradually creeps out of alignment. I don't know if this has been fixed
yet although I have a year-plus long report of the problem and we've
since worked around it with ESPUL, so I'm gun-shy of checking it again.
The new problem is specific to the LPQ1200 (maybe other LPQ series as
well). Occasionally, for sufficiently "large" values of "nn" in those
%2nn CCTLs, the printer instead treats it like a nospace, and will start
printing the next page on top of the last line of the current page, and
since there are no form feeds, it never adjusts itself back. I have
reproduced it several times with the same report, it fails in the same
places each time, yet it works on our networked 5000/640D. The odd part
is that I've examined the raw spoolfile control codes, and a given code
will work sometimes and fail others. I can't find any consistency,
other than the ones that "fail" are > %252, although there I can't find
any predictor of whether a given one will work or fail.
I'm hoping it is just a firmware issue, our firmware date codes are from
1997. I've placed a "software" call on this (it seemed more appropriate
than a hardware call) but won't hear anything until tomorrow, I'm
reasonably certain.
Jeff Kell <[log in to unmask]>
|
