[sane-devel] SANE 1.1.0 Release discussion
m. allan noah
kitno455 at gmail.com
Mon May 26 12:57:50 UTC 2008
On 5/26/08, René Rebe <rene at exactcode.de> wrote:
> 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
> 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...
"The truth is an offense, but not a sin"
More information about the sane-devel