> I am in contact with David to add some things to the sane api.
> One of this is to define how to handle a document feeder.
> The idea is very simple:
> We define a well known option "mode" that defines the scanmode
> such as "Flatbed", "Transparency Adapter" or "Automatic Document Feeder".
I wonder if this is short-sighted? Can you explain what it's for?
Regardless it should probably be called something other than "mode".
> If the option "mode" is set to "Automatic Document Feeder" xsane scans
> until it gets an error
> (such as out of paper).
What will this SANE option "mode" actually do? I don't mean in Xsane
(which is a frontend, and therefore doesn't HAVE any SANE options) I
want to know what it does in the backend.
> Functions such as unload page or load new page can be realised by a button
> that calls a function of the backend, there is nothing that must be defined
> for it!
Like this?
SANE_TYPE_BUTTON "unload page"
SANE_TYPE_BUTTON "next page"
There are existing buttons like this in the HP backend, I just want the
SANE documentation altered to make them "Well Known Options" and define
the exact behaviour in a central place.
It makes sense for XSane to use these buttons internally, while also
presenting them in the user-interface. You can programatically "push"
the button for each new page. In non-ADF-aware SANE apps, like the
current XSane, the buttons still work.
> The probelm is that the hp backend is not compatible to this.
> The umax backend does work this way so I would prefer a UMAX document feeder.
How does the UMAX backend work?
> Thanks, if I don`t get any other docfeeder, we will see if we can make the hp
> backend compatible!
But I don't understand what's wrong with it? Can you persuade me why the
UMAX way is superior (perhaps it will be obvious after you explain the
differences above).
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com