[sane-devel] Paper size detection for Fujitsu fi-5110eoxm (sane-fujitsu)?

[m. allan noah]

>        I am interested in adding automatic page length detection,
> similar to what the avision driver does I would like some pointers to the relevant technical specifications of the protocol used by the scanners that sane-fujitsu supports.  I do not see that feature in the cvs snapshot of 2009.03.22, but I may have missed something.  I am not saying that I am committing to implement this, but I would like to get the relevant technical specifications and see how hard it would be to try.

Fujitsu does not give out docs for the 'non-twain' scanners, but most
of them are similar enough to their big brothers, that you can glean
the required info from their docs. Since Fujitsu has used basically
the same protocol for 20 years, the 'OEM Manual' for the older M
series machines might shed some light:

http://193.128.183.41/home/v3__product.asp?pid=53&inf=doc&wg=0

>        If I get really ambitious, perhaps I might also try to implement a "bottom margin" option to scan a bit past the end to accomodate pages scanned at a slight angle,

Just tell the scanner the page-height and the scan area bottom Y is a
little longer than your true paper size. The scanner and the backend
will continue to send data even after the paper has run out. There is
also an overscan option (if your scanner supports it) which adds
similar padding to the top.

> and perhaps some support for the "scan" button also along the line of what avision has.

Every button and sensor of the machine is exposed as an option, but
you will need a special button daemon to do anything with the info.
There are a couple in the sane experimental cvs tree, and a couple
more can be found by searching the mailing list archives.

>        At first, I was hopeful that since the fujitsu backend's help
> text mentioned that it wanted to know the page size in order to do jam
> detection, that perhaps the driver was periodically querying the paper
> detection and scrolling the paper from the host computer, but a quick
> look at the source code seems to indicate that the paper size
> information is simply sent to the scanner, I guess locally controls
> the scrolling of the paper feeder.  So, I think I need more
> documentation about the protocols used by this scanner to figure out
> how to implement support for automatic paper length detection.

The scanner side is easy- just add a couple bits to mode select (page
code 0x3c) alongside overscan, and make sure that code gets sent to
the scanner whenever the user puts us in that mode. Later, after you
have transferred all the data out of the scanner (read until EOF), you
call get_pixelsize, and extract the scanner's thoughts on the paper
size. If the scanner supports width detection, it will work the same
way.

Unfortunately, the SANE API a little harder, because it expects the
backend to know the image details prior to transferring the first byte
of data. So, you have two (sub-optimal) choices:

1. block on sane_start when in this mode, buffer the entire image (or
images, in case of duplex) in the backend, and grab the detected size
and return. When the front-end moves on to call sane_get_parameters,
you will already have the final image data in ram, and you can return
accurate info. Subsequent calls to sane_read will just return from the
buffer. This mechanism works for length AND width detection.

2. allow sane_start to proceed normally, but return '-1' for the # of
lines in sane_get_params. This is the old 'hand-scanner' mode, which
is poorly supported by some frontends, because it requires them to do
the aforementioned buffering. The frontend must read from the backend
until EOF, and then guesstimate the number of lines based on the
number of bytes and the line width. This mechanism only works for
length detection.

There is another option, but it will require more (political) work-
change the sane API to allow the backend to flag that the scan params
are unknown, and the frontend should ask for them AFTER the EOF has
been sent. This is a bit of a wild suggestion, but I now have backends
for 3 different brands of machines that can do this, so it does not
seem too crazy anymore.

>        I assume that there is no automatic paper width detection, but
> would be happy to be corrected if I am wrong, especially because the
> images that I receive for the areas left and right of the paper being
> scanned seem to have some noise (that is, they are not columns of
> exactly one solid color), so I will probably have to do some research
> to determine if I can find software that reliably detects the paper's
> left and right edges.

Higher end machines do have AWD, but you bought the cheapest scanner
:) Why dont you just tell it the paper width is a little narrower, and
it will cut those margins off?

>        Finally, on a different subject, but one related to protocol
> documentation, I notice that nineteen .c files in
> sane-backends-2009-03-22/backends contain both the terms "USB" and
> "SCSI", so it looks like there are multiple drivers that claim to
> encapsulate some kind of scsi commands over USB.  This makes me wonder
> if there might be some SCSI standards on t10.org and/or USB device
> class specification on www.usb.org that might describe what most of
> these drivers do and perhaps provide an opportunity to factor out some
> common code.  On the other hand, if the fujitsu scanners are basically
> running a custom protocol, then I probably need some documents from
> Fujitsu, which I am sure would be helpful in any case.

There actually is a usb.org standard for scsi over usb, but no scanner
vendor uses it, AFAIK. The number of vendors that make SCSI machines
is actually dropping, and SCSI still has quite a bit of wiggle room,
so I dont think it is of much use. Particularly if you look at how
different some of these backends are from each other :)

On a side note, auto cropping, auto deskew and blank page skip are big
selling points for ADF machine vendors. Unfortunately, most of the
time these are actually features of the windows driver, and not the
machine. I would like to have the time/$ to write a 'meta' backend
that could sit between any existing backend and the frontend, and
provide these features, probably using mechanism #1 above.

allan
-- 
"The truth is an offense, but not a sin"