[sane-devel] HP OfficeJet 6700 ADF Problems

[Alex]

I apologize if this is the wrong place to ask, but I have run into a
couple of problems scanning from my HP OfficeJet 6700's ADF. The flatbed
scanner works perfectly and as expected, though. I'm running x86_64
Gentoo using sane-backends 1.0.23 and hplip 3.13.4 built with scanner
support.

I'm not really entirely sure what's going on with it, but when I use
scanimage like this:

scanimage -d 'hpaio:/usb/Officejet_6700?serial=[SERIAL]' --format=tiff
-p -v--source ADF --mode Color --resolution 300 -x 215.9 -y 279 -b
--batch-start=1 --batch-count=4

it feeds the documents and scans them each to out1.tif, out2.tif,
out3.tif, out4.tif just as expected. The progress percentage, however,
stops at some percentage before it moves on to the next page or
finishes. This percentage varies, and depends a bit on the -y argument.
If I leave it at the default (which I think is A4 sized), it'll stop at
about 75% for each page. If I have it at 279, for US letter sized, it'll
stop around 90%.

The files open fine in EOG (Eye of GNOME), but everything below the end
of the physical page is the transparent checkerboard. Additionally,
tiffinfo complains about a '"Bogus StripByteCounts" field'.

These would be fine if it worked in everything else, but if I run it
through graphicsmagick to convert it, like "gm convert out1.tif
out1.png", it complains "gm convert: Read error at scanline 3247; got 0
bytes, expected 7602. (TIFFFillStrip)." and doesn't create out1.png. If
I run it through imagemagick like "convert out1.tif out1.png", it complains:

convert: Bogus "StripByteCounts" field, ignoring and calculating from
imagelength. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/820.
convert: Read error at scanline 3248; got 0 bytes, expected 7602.
`TIFFFillStrip' @ error/tiff.c/TIFFErrors/560.

though it replaces the transparent part with black, or sometimes white
with a few black vertical lines through it.

If I try to run the same thing, with the -y decreased well below page
length, like at 100, the scanner audibly stops scanning half way through
the page and finishes sending the page through the ADF, though scanimage
says it "read more data than announced by backend". The .tif's made like
this open fine, with no transparent sections, and no errors or warnings
from imagemagick or graphicsmagick.

If I run it with SANE_DEBUG_HPAIO=50, the sane_hpaio_read() bytes_read=0
status=5, though it seems to do this with the small and regular -y values.

If I use --format=pnm, then in EOG below the page is black, gm convert
complains "gm convert: Unexpected end-of-file (out1.pnm).", and convert
complains:

convert: unable to read image data `out1.pnm' @
error/pnm.c/ReadPNMImage/899.
convert: no images defined `out1.png' @
error/convert.c/ConvertImageCommand/3044.

and doesn't create out1.png.

So, what I'm thinking is that the Officejet 6700 stops scanning a page
going through the ADF when it reaches the end of the page, and stops
sending any image data at that point. I'm guessing that scanimage
doesn't just fill any remaining space it expects because of -y with
white or black or anything and just writes out the file as it is, with
the expected remainder of the file missing, as far as other programs are
concerned.



Additionally, though less important, and likely due to how the scanner
actually works, if I use --batch-count and set it to less than the
number of pages in the ADF, the ADF will continue and feed all pages
through the scanner, though it is easy to see that due to their speed
and the sounds, it doesn't actually scan them.


Anyway, does anyone know of anyway to fix this problem, because I have
to scan a few thousand pages over the next few weeks into several pdfs,
and I'd like to write a bash script to sort-of automate a lot of it.

Thanks,
Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130516/32f0a922/attachment.pgp>