[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