[sane-devel] scanimage -b (batch) bugs?

m. allan noah anoah at pfeiffer.edu
Thu Jun 8 01:02:12 UTC 2006


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



More information about the sane-devel mailing list