[sane-devel] SANE2 proposal
Sun, 14 Apr 2002 22:45:21 +0200
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
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"?
> * 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
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
> * 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().
> * 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."
> 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()