[sane-devel] SANE2 proposal

Frank Zago fzago@greshamstorage.com
Mon, 15 Apr 2002 22:51:50 -0500 (CDT)


> > Hi Oliver,
> >
> > Here are my comments:
> >
> > - section 4.2.1
> >
> > Is there any reason why SANE_Word can't be suppressed? SANE_Word and
> > SANE_int are implemented the same and have close definitions.
>
> This comes frome SANE1. I don`t see a reason to change this. It does not make any
> problems.
> SANE_Word defines a size of a value but does not say anything about the contents,
> SANE_Int defines that it is an integer.

It's not because it comes from SANE1 that it's good. I just don't see the
point in keeping two nearly identical types. Just read any backend and
you'll that I'm not the only one confused.

> > - section 4.2.9
> >
> > SANE_OPTION_IS_SETTABLE(cap) should add that the option must also be
> > active.
>
> Where is the problem to test for IS_SETTABLE && IS_ACTIVE ?
> I am not sure if it makes any problems when we change this.

Because an option is not settable if it is not active. Thus the name is
misleading.

> > - I'd like to have all the SANE functions (sane_init, sane_open, ...)
> > declared in a structure. Only that structure would be exported. eg:
> >   static ... sane_open(...)
> >   static ... sane_init(...)
> >
> > backend_desc backendname_desc {
> >
> >   /* backend entry points */
> >   sane_open,
> >   sane_init,
> >   ...
> >   /* Backend info */
> >   "backendname",
> >   0,               /* backend capabilities */
> >   6544,            /* backend version */
> >   ...
> >   /* Reserved fields */
> >   NULL,
> >   ...
> >   0,
> >   ...
> > } backendname_desc;
> >
> > Some of the info here are from the SANE_Device structure. I don't think
> > they belong there.
> >
> > I know that would be a big change.
>
> Hm. Why such a big change, what advantages do you see?

1. only one symbol to export instead of about 10.
2. easier possibilities of expanding the standard through some reserved
fields without modifying other backends.
3. the scanner looks like a object.

> > - well known options (eg "source") and well know option values (eg
> >   "Flatbed") should have a corresponding #define to avoid mispellings
> >   and ease translations.
>
> Yes. They will be listed in sane2opts.h

Cool.

> > - the .desc format description should be added too, and expanded. I'd
> >   like to see an fcc id field.
>
> Can the backend find out the fcc number? I do not know about that.

No it cannot. It's more to build a database of scanner. Later, if someone
is interrested, a web based database could help to determine if a scanner
is supported by SANE or not. The fcc id helps because it usually doesnot
change when a scanner is rebadged, and also it indicates the real
manufacturer.

> What .desc format description?

The backend description files (eg doc/descriptions/umax.desc).

Frank.