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"
