[sane-devel] SANE2 proposal

[Henning Meier-Geinitz]

Hi,

On Sun, Apr 14, 2002 at 03:01:42PM +0200, Oliver Rauch wrote:
> sane2.tex is the SANE2 standard proposal

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. We don't know if all the information
  about 1, 8, 16 bits per sample are true for some MIME format, do we?
  
  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?
  
  Add a reference to the chapter about sane_get_parameters fort the exact
  meaning of formatdesc.
  
  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.
  
* 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).
  
* SANE_Device.backend_version_code: This one is a pretty good idea. I
  already thought about how to find out the version number of a
  backend connected to dll and there is currently no way.

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

* 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?
  
  "member", not "memeber".
  
* 4.3.3 (Backend implementation note):
  "The same information is ..." (instead of informtation).

* 4.3.4: The SANE_Status sane_open ..." line is too long.
  
* 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?
  
* 4.3.8 "Note that flags are compatible" (not compatibel).

* 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_FRAME_MIME: "within" insted of "whithin", "frame" insetad
  of "framy". 
  "Other formats may be ... but the only..." (the "as" is too much).

* 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?

* 4.4: "the individual channels of the ..." (the "in" is too much).

Bye,
  Henning