i would like to commit a fix for this bug. basically, the call to sane_cancel gets moved from within scan_it() to main(), just after the do/while loop.
for those using scanimage in non-batch mode (flatbed, single sheet simplex, etc) there is no difference in the order or timing of commands sent to the backend. for those using scanimage -b, there may be some change if the backend expects to get sane_cancel between pages. i doubt this is a likely problem, because such a backend would not work with scanadf, which only sends the sane_cancel at the end of a batch (after NO_DOCS). i will wait 24 hours for comments, because caution is the better part of valour :) thanks. allan On Fri, 2 Jun 2006, m. allan noah wrote: > sane.ps says on page 32 that after sane_read returns EOF, the frontend should > return to sane_start if more frames are desired, skipping sane_cancel. > > quoting David Mosberger-Tang: > * > * > In other words, the idea is to have sane_start() be called, and > * > collect as many images as the frontend wants (which could in turn > * > consist of multiple frames each as indicated by frame-type) and > * > when the frontend is done, it should call sane_cancel(). > * > Sometimes it's better to think of sane_cancel() as "sane_stop()" > * > but that name would have had some misleading connotations as > * > well, that's why we stuck with "cancel". > > scanadf works this way, scanimage -b does not. it calls sane_cancel between > each page. when scanning duplex, this can be a problem, as the backend may > have cached the backside into a buffer, and sane_cancel() will destroy that > buffer. > > i think this is a scanimage bug? > > allan > > -- "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
