hpoj-devel

Re: [hpoj-devel] hpinkjet testing results

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

I wrote:
> I finally got around to compiling and testing the new hpinkjet drivers.
> 
> I successfully printed in 300x300/normal mode with the following drivers:
> DJ8xx -- OfficeJet R80
> DJ9xx -- OfficeJet G85, K80, PSC750
> 
> I also tried 600x600/photo mode, but it didn't look as good, probably
> because I wasn't printing on photo paper.
> 
> I also tried the DJ6xx driver on the OfficeJet 570, but it didn't work.
> It looked like the printer stopped accepting data after receiving about
> 13 packets of print data.  Has anybody else tried this on the OfficeJet
> 500 series?  For now I updated the "Supported devices" page with the
> assumption that only the old cdj550 driver will work on the OfficeJet 500
> series.
> 
> I will test more models later.

Hi,

Today I finished testing the rest of the models that should work with the
hpinkjet drivers.  The following can be added to the "successful" test list
above:
DJ8xx -- OfficeJet T65
DJ6xx -- OfficeJet 570, 600, 700, PSC 390

Keep in mind that even though I generally test with only one model in each
series, the results should apply to all models in that series.  Of course,
if anybody finds that not to be the case, then please let me know.  :-)
I also didn't test with the PSC 500, but it should be the same as the R
series (DJ8xx).

I managed to resolve the problem I was experiencing yesterday with the 570,
which actually applied to all of the models that use the DJ6xx driver.  It
turned out to be the exact same problem that Joe recently reported where
print jobs didn't come out after I rearranged the escape sequences that
ptal-printd sent before jobs.  This time, the hpinkjet code was the culprit.
The bug was in global code rather than in code specific to the DJ6xx driver.
I hacked one file in it to prevent it from sending the <Esc>E before the
UEL (<Esc>%-12345X) before the job.  The patch is available in a new section
at "http://hpoj.sourceforge.net/todo.shtml", and I will notify the hpinkjet
developers so they can hopefully include it in later releases.

Joe, since I had trouble getting the OfficeJet 600 to work, I was surprised
that you were successful.  I'm guessing that you were printing directly to
/dev/lpX instead of ptal-printd, because it worked for me when I did that.
I even tried downgrading to 0.7, and that didn't work either.

I didn't test the DJ6xxP (photo) driver, which should work on the OfficeJet
700 and PSC 300 series with a special photo cartridge installed, because I
don't have any photo cartridges, which contain black, light cyan, and light
magenta ink.  If anybody out there has either an OfficeJet 7xx or PSC 3xx
with a photo cartridge installed, I would be interested to know if the DJ6xxP
driver also works (after applying the above patch), and how the print quality
compares to the regular DJ6xx (non-photo) driver.

David

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

Re: [hpoj-devel] hpinkjet testing results

[Joe P. <joe...@sn...>]

On Sunday 01 April 2001 07:52 am, David Paschal wrote:

<....>
> 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?

It does work now.

I originally tested the printing system with the drivers installed from the 
0.93 rpms, but have since updated the ghostscript-hpijs rpm to ver. 0.94, 
built from the SRPM. I now have hpijs installed from the (patched) tarball 
instead of the hpijs rpm.

'rpm' complains about an unsatisfied dependency due to the hpijs rpm not 
being installed, but since hpijs actually is installed, there is no real 
problem. To avoid some future confusion, I'll reinstall the hpijs rpm if it 
becomes available in a patched version.
 
-- 
Joe

Re: [hpoj-devel] hpinkjet testing results

[Joe P. <joe...@sn...>]

On Saturday 31 March 2001 07:01 am, David Paschal wrote:

<...>

> Hi,
>
> Today I finished testing the rest of the models that should work with the
> hpinkjet drivers.  The following can be added to the "successful" test list
> above:
> DJ8xx -- OfficeJet T65
> DJ6xx -- OfficeJet 570, 600, 700, PSC 390
>
> Keep in mind that even though I generally test with only one model in each
> series, the results should apply to all models in that series.  Of course,
> if anybody finds that not to be the case, then please let me know.  :-)
> I also didn't test with the PSC 500, but it should be the same as the R
> series (DJ8xx).
>
> I managed to resolve the problem I was experiencing yesterday with the 570,
> which actually applied to all of the models that use the DJ6xx driver.  It
> turned out to be the exact same problem that Joe recently reported where
> print jobs didn't come out after I rearranged the escape sequences that
> ptal-printd sent before jobs.  This time, the hpinkjet code was the
> culprit. The bug was in global code rather than in code specific to the
> DJ6xx driver. I hacked one file in it to prevent it from sending the <Esc>E
> before the UEL (<Esc>%-12345X) before the job.  The patch is available in a
> new section at "http://hpoj.sourceforge.net/todo.shtml", and I will notify
> the hpinkjet developers so they can hopefully include it in later releases.
>
> Joe, since I had trouble getting the OfficeJet 600 to work, I was surprised
> that you were successful.  I'm guessing that you were printing directly to
> /dev/lpX instead of ptal-printd, because it worked for me when I did that.
> I even tried downgrading to 0.7, and that didn't work either.

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? 

-- 
Joe