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