[sane-devel] SANE2 proposal

[Oliver Rauch]

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.


>   We don't know if all the information
>   about 1, 8, 16 bits per sample are true for some MIME format, do we?

May be correct. Possibly the value depth makes no sense in MIME format.

 
>   I'm not sure if we should even mention the old SANE1 frame types.
>   If someone really wants to use them, he should looak at the SANE1
>   standard. Or is tehre a special reason for this?

Once is to tell why values 5 and 6 are used for SANE2 frames,
onther thing is the idea that a frontend may decide to support
SANE1 and SANE2 backends.
It also would be possible to start from 0 and remove the SANE1
frame types. But this way it would be harder to write a
SANE1+SANE2 frontend.
This is one of the points that have to be discussed. May be
it makes more sense to remove all SANE1 things.

> 
>   Add a reference to the chapter about sane_get_parameters fort the exact
>   meaning of formatdesc.

There is a describing point formatdesc in sane_get_parameters. What do you think about?

> 
>   By the way: Shouldn't the name be "format_desc"?

Changed
> 
> * SANE_Device.email_backend_author: I'm not sure, if this really
>   belongs into the structure (and not into the man page and HTML page).
>   If it's in the code, I would prefer to also have the name of the
>   author in this entry. This makes it easier to find him when the
>   email address doesn't exist any longer.

The email address should look like this:

Oliver Rauch <Oliver.Rauch@XSane.org>

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.

 
> * SANE_Device.device_location: I don't understand this one. Which
>   location? My device is on the table 1.5m to the right of me :-)
>   Do you mean the backend? A URL to the vendor? Or a path name?
>   And why should it be read from the config file (the backend doesn't
>   even need one and I'm not sure if we should mention this).

No, I think about a real physical location.
Imagine you are at work or in the university and 200 computers have
access to a scanner via network, then it is necessary that a user
can find out where he finds the scanner, so the entry could look like
this:

building 93, 2nd plane, room 2113

> * SANE_Device.backend_capability_flags: Can you give an example for
>   such a flag and what the frontend should do with it?

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.

> 
> * 4.2.10 InternationAlization (missing "a").
>   Be clear. "Should" is should. There is no "preferrable" necessary.
>   Maybe we should cite the RFCs' meaning of "MUST" and "SHOULD"
>   somewhere in the standard?

We can write "must" but I do not want to force this here, it also does
work when the backend is written in chineese and we have a chineese
to english translation

> * SANE_Parameters.flags: To be consistent with SANE_FLAG_LAST_FRAME
>   shouldn't the next falg be the other way round: SANE_FLAG_LAST_IMAGE?
>   Or is this for SANE1-Compatibility?

Yes, this is for SANE1 compatibility. We tried to keep the data in the same
place like SANE1 and I think this way a meta backend can translate
simply between a sane1 backend and a sane2 frontend or a frontend may
decide to support sane1 and sane2 backends.


> * 4.3.8 SANE_Parameters.bytes_per_line: I would move the comment about
>   block sizes to sane_read().

Done

> 
> * 4.3.8 SANE_Parameters.depth: See comment on 3.2 abouth depth.

> * 4.3.8 SANE_Parameters.proposed_filename: The sentence starting with
>   "Special care..."  contains a bit too much brackets :-) It also
>   references a point "a)" which doesnt exist as "a)". Maybe: "...not an
>   issue here, because that's only a propose filename extension as
>   mentioned above."

Good.

> 
> 
> 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?
As suggested by someone we should allow to add such a flag to sane_start()


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