HP DeskJet 3052A

[WAS2013]

Alex Taylor suggested I open a ticket on this problem. This is a USB Port device. Using the attached PPD file, its print quality would be characterized as Good or Very Good. The problem is that after the print job is completed CPU Usage spikes to 99.9%; during the print job there is no spike. Opening the CUPS Administration page in Firefox shows the following, under the respective tabs, after the print job: Jobs State "No %%BoundingBox: comment in header!"

Printers Status Processing - "Processing page x..."

The page number mentioned is always the number 1 greater than the last page of the document. Ergo, it is what I would characterize as an imaginary page.

Using the C-A-D utility after the spike starts, and then List shows CUPSD.EXE CUPSD.EXE USB.EXE Killing both instances of CUPSD.EXE does not eliminate the spike. Repeated attempts to kill USB.EXE always fails.

Using the Run TOP tool of the C-A-D utility shows that it is USB.EXE that causes the spike.

A reboot, after CUPSD.EXE is killed, solves the spike. If they are not killed, it is necessary to go to the CUPS Administration page and then Jobs to cancel the print job; otherwise the job will continue to print over-and-over until cancelled despite the reboots.

I understand from Alex that Paul is trying to address the problem w/ USB printers. he also suggested the possibility of me trying to network the printer instead. I could try I suppose but it would be inconvenient because of the physical setup (the cable being in a walkway in that event), and still possibly presenting the same issue as the other computer would necessarily be connected to the printer by the USB Port.

[WAS2013]

One thing occurred to me as but a _potential_ area of investigation for a solution to the problem w/ USB printers.

I remembered an option that exists w/ many (if not most) LPT1 dot matrix printers; it does not appear to be an option under CUPS (or at least w/ the USB printers). This is the option under the "Job Properties" selection on the "Printer driver" tab: viz, "Form Feed Control".

One of the options there, of course, is "None", in opposition to the "Conditional" or "Compulsory" options. I wonder if there is some code that could be inserted somewhere to mimic the None command? For I wonder if the problem could be that there is some kind of default to Compulsory, so that <USB.EXE> is therefore looking to another page or another form to feed?

Just a thought.

[psmedley]

I have ported libusb 1.0 to OS/2. I will send a link to a usb.exe built with it to this ticket that may help.

I'll also try and put together a new hplip package that includes the HP printing backend (hp.exe) that may also help.

[psmedley]

Please replace usb.exe with the one from: ​http://smedley.id.au/tmp/usb.zip and see if it helps.

Note this usb.exe also requires gcc446.dll and libusb10.dll

libusb is available from my site (​http://os2ports.smedley.id.au)

[WAS2013]

Paul, Just happened to check the ticket, and only today found your kind comments.

THANKS MUCH! It seems this could have solved the problem. (I must say the new file is certainly a Heckuva lot bigger than the predecessor ...)

I printed a 4-page PDF file and, while holding my breath, the CPU did _not_ spike after completion. Looking at the "Jobs" page, nothing is shown. There does seem a slight hiccup since, looking at the "Printers" page it shows, under Status, "Idle - "Processing page 5..."". I then tried to print a 1-page PDF file and it printed fine, despite the putative pending job, and again did not spike - though after completion the page now showed "Idle - "Processing page 2..."".

Maybe though on a reboot this will clear up. Plus, I didn't try to reboot after replacing the <USB.EXE> file or adding the <LIBUSB10.DLL> file. Perhaps this could have contributed to the putative pending file also.

[WAS2013]

After the above I replaced <USB.EXE> in my 2.2 partition and booted to it. Printing a new job I was not surprised to see, after the job was finished, an "Idle - "Processing page x..."" entry. While the job was printing I noted on the Jobs tab that it showed

processing since Sat Sep 7 18:01:16 EDT 2013 "No %%BoundingBox: comment in header!"

Perhaps then this absence is the cause of the "processing error"?

Still, since the new <USB.EXE> no longer consumes all the CPU resources nor interferes w/ later print jobs, it would seem this "deficiency" is probably cosmetic only.