[sane-devel] SANE 1.1.0 Release discussion

[m. allan noah]

On 5/26/08, René Rebe <rene at exactcode.de> wrote:
> Hi,
>
>  ps: this time to the list as well :-)
>
>  m. allan noah wrote:
>
> > On 5/26/08, René Rebe <rene at exactcode.de> wrote:
> >
> > > Hi Allan,
> > >
> > >  can you explain the paper width option to me? Why can we
> > >  not simply use br x/y?
> > >
> > >  Actually I got a Fujitsu scanner here and find the duplicate
> > >  paper width option annoying at best.
> > >
> >
> > it is not duplicate. it is used by the backend to properly center the
> > users x/y params to the moving paper guides. otherwise, if they want
> > to scan an entire sheet of A5, they have to set the tl_x/y to some
> > weird value that they have to calculate from the scanner's maximum
> > width.
> > how do you handle this in avision now?
> >
>
>  not at all, I consider this a front end job, it also avoids the simple
>  arithmetic in every backend. The page size then also appears to indirectly
>  change the maximal scan area? I find this way more "complex" than just
> allow
>  frontends to center the scan area on the maximal area.

ahh, but you assume that the paper guides always center the paper. i
have a lexmark that i am working on, which has only one moving paper
guide. this code should be done in the backend, especially since it is
so simple :)

> > >  Aside the already mentioned button to use some more extend-able
> > >  XML encoding instead of a hardcoded set, I wonder if it is
> > >  good to expose sensors, frontends would rarely (if ever?) want
> > >  to check for them explicitly and the backend must check the
> > >  sensors before or during scan to generate proper errors
> > >  accordingly anyway.
> > >
> >
> > don't assume that sensors only indicate errors. the paper-in signal is
> > quite useful in high volume apps- the front-end can start scanning
> > immediately.
> >
>
>  Ah ok, media presense is indeed useful, granted. One could also
>  start scaning on cover close, indeed. I was just afraid on exposing
>  random sensors (home, etc.) without a real need.
>
>
> > xml does not fix this problem, cause we would still have to define a
> > schema so that front-ends could interpret it. so, lets just avoid the
> > xml dependency.
> >
>
>  Still, many Avisions have Simplex / Duplex buttons, and some, like the
>  HP 7400, allow resolution, color mode, and number of copies to be
>  set on the device. How would you like to handle those then (and yes,
>  the Avision backend does not export the 7400 options, yet, as I had
>  no idea, beside a pre-formated  string message, how to expose them)?
>
>  The problem with letting some buttons change the backend internal
>  state configuration (resolution et al.) and some be exposed to the
>  frontend (scan, fax, print) exposes two problems: One the frontend
>  UI (if any) does not update when the user changes scanner values,
>  and second may yield to scans with other parameters than the frontend
>  believed to scan with. Having one flow of hardware "notifications"
>  might be more structured and frontend friendly.

you have a good point, but only if the button names dont collide with
existing options, or we need a boolean control that the user can use
to state that those options are gotten from hardware...

allan
-- 
"The truth is an offense, but not a sin"