[sane-devel] SANE2 proposal

[Oliver Rauch]

Henning Meier-Geinitz wrote:
> 
> Hi,
> 
> On Sun, Apr 14, 2002 at 10:45:21PM +0200, Oliver Rauch wrote:
> > Henning Meier-Geinitz wrote:
> >
> > > Some questions and comments that came to my mind while reading the
> > > standard the first time (so I may have missed something):
> > >
> > > * 3.2 Image data format and 3.2.1 Image transmission:
> > >   The radical change in frame types and frame transmission should be
> > >   mentioned earlier in the text.
> >
> > Suggestions are welcome.
> 
> Ok. I append a LaTeX code for a revised chapter "Image data format". I
> mostly moved paragraphs around. I removed the exact descriptions for
> the old frame types. Added references to sane_get_parameters. Added
> definition of the order of bits in 1-bit modes.
> 
> What do you think about it?

Ok. applied your version.

> > There is a describing point formatdesc in sane_get_parameters. What
> > do you think about?
> 
> That's ok. I just wanted a link to that desription (\ref{some_section}).

Where shall I put the ref?


> > The email address should look like this:
> >
> > Oliver Rauch <Oliver.Rauch@XSane.org>
> 
> Ok, better explicitely talk about the name.
> 
> > it makes sense to put the email address into the backend because
> > if someone uses a backend via network he may not have the manpage
> > of the backend.
> 
> Ok. Maybe also a URL to the backend homepage?

Ok, added

> > building 93, 2nd plane, room 2113
> 
> Ah, ok. Then my first guess wasn't that wrong. Maybe just add your
> example to the descriptions, that makes it pretty clear.

added

> > This is planned for future extensions.
> > Let?s say we add a new feature that is not defined in the sane-2.0.0
> > standard (e.g. audio support for a camera) then it is necessary that
> > the backend can tell te frontend if special features are supported or
> > not.
> 
> But the features must be supported by some addition function or frame
> type in this case, needn't it?

not necessaryly. The MIME format allows to tranfer all kind of data.
May be it gets important that the frontend knows that the backend can
read barcodes and transmit these in a MIME format, then we could define
one bit for this and so the backend can inform the frontend that it does
support bar codes.


> 
> > > As an addition, we should make clear what can be changed in a
> > > SANE_Option_Descriptor and when. Currently it must only be "vaild" and
> > > the address stay the same. E.g. is the backend allowed to change the
> > > type of option? Or only capabilities?
> >
> > I think it is allowed to change all in sane_control_option when
> > SANE_INFO_RELOAD_OPTIONS is set - or am I wrong?
> 
> Be carefull. You can change the value and (at least I think so)
> SANE_CAP_INACTIVE. You don't know if SANE_INFO_RELOAD_OPTIONS means
> that the options are reloaded immediately. info can even be 0.
> Even when sane_get_option_descriptor is actually called, it's
> currently not allowed to change the returned address until sane_close().
> The net backend had this bug until recently.
> 
> >From the words of the current standard you are not allowed to change
> the option descriptor (at least that's my interpretation).
> E.g. you can't change a constraint or string list.

I don`t think it makes sense to allow to e.g. change an option from a
constraint_range to a word_list. If a backend needs this then it has to
define one option as word_list and another option as range and disbale
the one and enable the other. But this does not work with well known
options because an option name has to be unique.

I think it is possible to change the list items of a list.

Bye
Oliver

-- 
Homepage:	http://www.rauch-domain.de
sane-umax:	http://www.rauch-domain.de/sane-umax
xsane:		http://www.xsane.org
E-Mail:		mailto:Oliver.Rauch@rauch-domain.de