Comment 4 for bug 256541

On Sun, Aug 10, 2008 at 12:17 PM, dwelch91 <email address hidden> wrote:
> Thanks for your submission, Kyle. We will take a look at your code and
> determine if we can incorporate it in a future release. We would most likely
> port it to C or Python, as Perl is not one of the languages we use in HPLIP,

Heh, I understand entirely. I tend to use C for a lot of things, but
when trying to hack something together quick using
HTTP+XML+random-text-goop-of-the-week I resort to Perl for sheer
prototyping speed. Just as reference, I did notice one misfeature
with the last version of the Perl script, I'd turned off tempfile
cleanup for debugging and forgot to turn it back on again; to fix just
change the "CLEANUP => 0" bit on line 412 or so to be "CLEANUP => 1".

> but it looks like you have done the hard part of figuring out how to make it
> work. It looks like you are monitoring the scan button every 5 seconds?
> Does that seem like an acceptable rate? (Responsive enough to the user, but
> doesn't slow down the PC?)

5 seconds seems to be roughly what the HP windows-only scanner
software uses and that seems about right in my testing. Any slower
and it starts to feel laggy and if you don't poll at least every 30
seconds or so then the scanner will sometimes time out waiting for a
connection.

I'm sure that there is some measurable load on the system from the
frequent polling, but that seems entirely due to the crappy
notification protocol designed into the printer. I certainly wouldn't
want to install such software on my laptop, it would be yet another
factor in killing the battery life; sitting there waking up the CPU
and polling the network every 5 seconds or so. Good thing I don't
much care about repetitive tasks running on their samba server :-D.

I did notice one other problem with the script the way it stands;
duplex scanning doesn't seem to work although I thought it did before.
 The scanner scans the front of the first page (from the ADF), then
flips it over while scanning the back. Then when it goes to flip it
over the second time to drop it in the out-bin, it doesn't quite clear
the last inch of the page from some part of the machinery before
reversing to re-feed the page. The result is that it tries to
back-feed the page the wrong way across the glass in front of the scan
head and gets all jammed up.

I double-checked and this *doesn't* happen while doing a duplex copy
from the keypad on the front of the machine, so it's not a hardware
problem. I seem to recall having successfully done a duplex scan
using "scanimage" before, so perhaps the corrected paper size settings
or something are confusing the microcontroller into screwing up the
duplex mechanism. When I get a chance I'll try to munge the options
to see if I can get it to work again.

The only other problem (I don't remember if I mentioned this before)
is that the contrast seems very low; the images are washed out and
faded towards white. I tried patching the source to send
<AutoExposure>true</AutoExposure> in the <wscn:CreateScanJobRequest/>
SOAP call the same way the Windows driver does, but that didn't seem
to have any effect. Neither does manually specifying "--contrast 50"
or "--contrast -50" on the command line. At some point I'll probably
dive into the pcap file from the windows session again, but for now
I'm just postprocessing with some command-line tools.

Please do keep me in the loop on further developments of this; I'm
anxious to get (at the very least) the
/usr/share/hplip/data/models/models.dat fixes and hopefully the
<ScanIdentifier>/<JobToken> updates upstream. Then maybe Debian will
pick them up and I won't need to patch and rebuild the hplip package
when updates come out.

Cheers,
Kyle Moffett