Re: [hpoj-devel] hpinkjet testing results

[<pa...@rc...>]

Joe Piolunek wrote:
> I set up the queue to print to /dev/lpX, according to the hpinkjet 
> instructions. I initially tried to use ptal-printd, but had no luck with it.
> 
> I'm a little confused about using ptal-printd in combination with the 
> hpinkjet driver, which comes with its own 'print server' (hpijs). Will 
> ptal-printd continue to be important?
> 
> Is the patch meant to allow the hpinkjet driver to print to ptal-printd? 
Hi, Joe.  The reason you couldn't use hpinkjet through ptal-printd is very
similar to the problem you reported recently with printing through
ptal-printd after I rearranged the pre-job escape sequences.  It turns out
that the OfficeJet 500, 600, 700, and PSC 300 don't tolerate receiving
print jobs with <Esc>E at the job beginning while in MLC mode (which is the
case when ptal-mlcd is in control), although they don't seem to mind when
in "raw" mode (which is the case when printing directly to /dev/lpX).

The patch I posted merely prevents hpijs from generating this <Esc>E at the
beginning of the job, which by extension makes the printer happy when the
job is routed through ptal-printd and ptal-mlcd.  When you get a chance,
would you try out this patch (to Header.cpp in the hpijs directory) and
verify that you can now print through ptal-printd?

hpijs is a helper process spawned by ghostscript that takes a raster image,
already converted from PostScript by ghostscript, and generates and hands
back to the parent ghostscript process a PCL print job, which in turn is
handed back to the spooler (such as lpd) and written to the device (such as
a character device or named pipe node under /dev).  (Or at least this is how
I understand it from talking to the developers and reading the documentation,
since I haven't examined the code in great detail.)

For this reason, I expect ptal-printd will continue to be needed as long as
print spoolers are designed for the model of opening a character device and
writing data to it.  The alternative would be to make all the various print
spoolers out there PTAL-aware or at least able to easily pass the data to an
arbitrary command, such as ptal-connect, neither of which I see happening.

David