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 <[email protected]> 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:[email protected]
