[sane-devel] 'scan' button
m. allan noah
Thu, 23 Dec 2004 13:42:35 -0500 (EST)
On Thu, 23 Dec 2004, Rich Duzenbury wrote:
> On Thu, 2004-12-23 at 09:52 -0500, m. allan noah wrote:
>> rich, there has been a bit of discussion about how to handle buttons on
>> scanners, though MFD's may be different if they use a separate usb
>> interface for each function. Search the archives of this list for more
> I'll give them a search, is there a decent search interface somewhere
> other than archive by month?
umm, the search line on this page:
>> but i wonder, if the button issue was solved, how would your system know
>> which user pressed the button? how would it know who to notify? how is the
>> device related to user accounts currently?
> In this case, all scan stations will collect only one type of document -
> orders - and forward them to a central operator for input into the
> computerized ordering system, so it doesn't matter which person presses
> the scan button.
we do something similar with a custom c/perl app that uses lwp::request to
http POST the scans back to a central server, where a mod_perl app stores
them in mysql db. we identify the scanning station, but not the user.
> All incoming orders are to be stored in a particular place on the
> network, and the only tricky bit is to notify the operator of new
> orders, much the same as an email application notifies it's users of a
> new e-mail message. A frontend program that shows the queue of incoming
> scans and allows the operator to dispatch them ought to already exist
> Even in my simple case, we do have one routing issue. Some orders are
> routine and others are considered high priority. High priority orders
> must be at the top of the list before the routine orders. How will we
> know? The user fills in a box if the order is high priority. We will
> need to examine a region of the page and determine if the check box is
> filled in.
does the machine have multiple buttons? if so, could you have the user
press a different one on high-priority docs?
> Perhaps later we will have other types of forms to deal with. It seems
> that we should be able to content scan for a barcode that indicates the
> document type, and base routing decisions on the document type. Perhaps
> we need a two forms - one with a high priority barcode, and another with
> a regular priority barcode.
we do something very similar, a couple dozen forms, but all have a barcode
in the same place. there is a cron-job on the server that runs every
couple minutes and processes the scans.
we de-skew, find barcode, upend and align page if needed, read barcode,
omr the rest of the sheet, then store in db. human never looks at pages.
> In summary, some organized content of the document should be enough to
> determine the routing.
you will find it difficult to do, but not impossible, given the number of
ways a barcode can be obscured or scanned out of place. i wrote a good bit
of code to clean up some of the more common problems, but it is not
> If you have any insight into this kind of routing under linux, please
> let me know.
we can discuss off-line how to do it yourself, but i dont know of any
such apps which are free software. Principia product's Remark Office works
reasonably, as long as the scan quality is very good and you dont mind
using windows. i could not get it to run under WINE. we used it by putting
the images and .bat files out to a samba share, and using windows sheduler
to run on a windows pc. now we do it all ourselves.
> Current Conditions in Des Moines, IA
> Temp -0.4F, Windchill -15.5F
> Winds out of the North at 9mph
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera